Zum Hauptinhalt springen

Systemarchitektur

Zenovay ist als verteiltes System aus vier miteinander verbundenen Services aufgebaut, jeder für seine spezifische Rolle optimiert. Das Verständnis, wie sie zusammenarbeiten, ist für effektive Entwicklung und Debugging wesentlich.

Service-Übersicht

Unsere Plattform besteht aus vier Hauptservices, jeder unabhängig im Cloudflare-Edge-Netzwerk deployed:

  • Landing (zenovay.com) – Marketing-Site und öffentliche Seiten. Statischer Next.js-Export, optimiert für SEO und schnelles Laden.
  • Auth (auth.zenovay.com) – Zentralisierter Authentifizierungsservice. Verarbeitet Login, Registrierung, OAuth, SSO und MFA-Flows.
  • App (app.zenovay.com) – Haupt-Analytics-Dashboard. Echtzeit-Datenvisualisierung, Session-Replay und Team-Management.
  • API (api.zenovay.com) – Backend-Services. Event-Tracking, Datenverarbeitung, Abrechnung und Drittanbieter-Integrationen.

Service-übergreifende Kommunikation

Services kommunizieren über klar definierte Muster, die Sicherheit wahren und nahtlose Nutzererfahrungen ermöglichen:

  • Auth → App: Nach erfolgreicher Authentifizierung werden Nutzer mit sicheren Tokens zur App weitergeleitet. Der Session-Zustand wird über Tabs hinweg mit der BroadcastChannel-API synchronisiert.
  • App → API: Das Dashboard stellt authentifizierte Anfragen an die API mit Bearer-Tokens. Alle Analytics-Abfragen, Abrechnungsoperationen und Datenmutationen fließen hier durch.
  • Tracking → API: Das leichtgewichtige Tracking-Skript (<5 KB) sendet Events direkt an die API über POST-Anfragen an werbeblocker-freundliche Endpunkte.

Token-Flow

Authentifizierung folgt einem sicheren Flow über Services hinweg:

  • Nutzer meldet sich auf auth.zenovay.com an
  • Supabase gibt Zugriffs- und Refresh-Tokens aus
  • Tokens werden in httpOnly-Cookies für XSS-Schutz gespeichert
  • App validiert Tokens bei jeder Anfrage über Middleware
  • API-Endpunkte verifizieren Bearer-Tokens zur Autorisierung
  • Refresh-Tokens rotieren automatisch, um Wiederverwendung zu verhindern

Cloudflare-Deployment

Wir nutzen das Cloudflare-Ökosystem umfassend für Performance und Zuverlässigkeit:

  • Pages: Statisches Site-Hosting für Landing- und App-Frontends
  • Workers: Serverlose API-Funktionen, die am Edge laufen
  • KV: Key-Value-Storage für Rate-Limiting, Session-Locks und benutzerdefiniertes Endpunkt-Mapping
  • R2: Object-Storage für Team-Avatare und Session-Aufnahmen
  • Turnstile: Bot-Schutz ohne Nutzerreibung

Datenbankarchitektur

Supabase (PostgreSQL) dient als unsere primäre Datenbank mit mehreren wichtigen Design-Entscheidungen:

  • Teambasierte Multi-Tenancy: Alle Daten sind auf Teams, nicht auf einzelne Nutzer, beschränkt. Das ermöglicht standardmäßige Zusammenarbeit.
  • Row Level Security (RLS): Datenbankebenen-Richtlinien stellen sicher, dass Nutzer nur auf Daten zugreifen können, für die sie autorisiert sind.
  • Echtzeit-Abonnements: Live-Besucherdaten werden über Supabase-Echtzeit-Kanäle auf Dashboards gestreamt.
  • Trigger zur Durchsetzung: Plan-Limits und Nutzungsverfolgung werden auf Datenbankebene durchgesetzt, nicht nur im Anwendungscode.