HavenDOCS
Back to Home

Technical Architecture Overview

Haven is built on a high-performance, distributed stack designed for low-latency real-time collaboration.

System Diagram

graph TD
    User((User)) -->|HTTPS| NextJS[Next.js App Router]
    User -->|WSS| MatchWS[Matchmaking WS Server]
    
    subgraph "Main Application (Next.js)"
        NextJS -->|Auth / Proxy| Middleware[Auth Middleware]
        Middleware -->|Headers| API[API Routes]
        API -->|Read/Write| DB[(Supabase Postgres)]
        API -->|Rate Limit| Redis[(Upstash Redis)]
    end

    subgraph "Real-time Layer"
        MatchWS -->|Signaling| WebRTC[P2P WebRTC]
        User --- WebRTC
        NextJS -->|LiveKit SDK| LiveKit[LiveKit SFU]
    end

    subgraph "Security Gateway"
        Middleware -->|Verify JWT| SupabaseAuth[Supabase Auth]
    end

Core Technologies (2026 Stack)

  • Frontend: Next.js 16 (App Router), Tailwind CSS, Radix UI.
  • Backend: Next.js API Routes + Dedicated Matchmaking microservice.
  • Database: Supabase PostgreSQL (Auth, Profiles, Sangha state).
  • Matchmaking & Signaling: Dedicated Node.js WebSocket Server (10K+ concurrent capacity).
  • Real-time Media:
    • 1-on-1: Pure P2P WebRTC (signaled via WS).
    • Haven: LiveKit SFU (Selective Forwarding Unit) for high-scale rooms.
  • Caching & Safety: Upstash Redis (Global Rate Limiting, Session Caching).

Request Lifecycle

  1. Gatekeeper (Middleware): Every request is intercepted by middleware.ts. It performs IP-based rate limiting via Redis and verifies the user's session with Supabase.
  2. Identity Handover: The middleware injects x-user-id and x-middleware-verified headers, allowing internal API routes to skip expensive auth calls.
  3. The Vibe (UI): React Server Components handle the data fetching for Haven lists and profiles, while Client Components manage the persistent WebRTC/LiveKit states.