Zenovay is built as a distributed system of four interconnected services, each optimized for its specific role. Understanding how they work together is essential for effective development and debugging.
Service Overview
Our platform consists of four main services, each deployed independently on Cloudflare's edge network:
- Landing (zenovay.com) — Marketing site and public pages. Static Next.js export optimized for SEO and fast loading.
- Auth (auth.zenovay.com) — Centralized authentication service. Handles login, signup, OAuth, SSO, and MFA flows.
- App (app.zenovay.com) — Main analytics dashboard. Real-time data visualization, session replay, and team management.
- API (api.zenovay.com) — Backend services. Event tracking, data processing, billing, and third-party integrations.
Cross-Service Communication
Services communicate through well-defined patterns that maintain security while enabling seamless user experiences:
- Auth → App: After successful authentication, users are redirected to the app with secure tokens. Session state is synchronized across tabs using the BroadcastChannel API.
- App → API: The dashboard makes authenticated requests to the API using bearer tokens. All analytics queries, billing operations, and data mutations flow through here.
- Tracking → API: The lightweight tracking script (<5KB) sends events directly to the API via POST requests to ad-blocker-friendly endpoints.
Token Flow
Authentication follows a secure flow across services:
- User logs in at auth.zenovay.com
- Supabase issues access and refresh tokens
- Tokens are stored in httpOnly cookies for XSS protection
- App validates tokens on each request via middleware
- API endpoints verify bearer tokens for authorization
- Refresh tokens rotate automatically to prevent reuse
Cloudflare Deployment
We leverage Cloudflare's ecosystem extensively for performance and reliability:
- Pages: Static site hosting for landing and app frontends
- Workers: Serverless API functions running at the edge
- KV: Key-value storage for rate limiting, session locks, and custom endpoint mapping
- R2: Object storage for team avatars and session recordings
- Turnstile: Bot protection without user friction
Database Architecture
Supabase (PostgreSQL) serves as our primary database with several key design decisions:
- Team-based multi-tenancy: All data is scoped to teams, not individual users. This enables collaboration by default.
- Row Level Security (RLS): Database-level policies ensure users can only access data they're authorized to see.
- Real-time subscriptions: Live visitor data streams to dashboards via Supabase's real-time channels.
- Triggers for enforcement: Plan limits and usage tracking are enforced at the database level, not just in application code.