DEV Community: Krish Anand

Weave: Building a Production Video Conferencing Platform with E2E Encrypted Local Recording

Krish Anand — Wed, 22 Jul 2026 11:59:35 +0000

A comprehensive system design walkthrough — HLD + LLD

Introduction

Weave is an open-source video conferencing platform that solves a fundamental problem: internet quality should never compromise recording quality. Unlike Zoom or Google Meet, which record server-side (and lose quality on bad connections), Weave records locally on each participant's device in encrypted 60-second chunks, then intelligently merges and processes them in the cloud.

The platform includes:

Real-time video conferencing (powered by Jitsi Meet)
Local chunk-based recording with AES-256-GCM encryption
Per-meeting Content Encryption Keys wrapped with RSA-OAEP-256
An in-browser video editor with timeline, transitions, overlays, and effects
Multi-camera (multicam) editing with speaker detection and auto-cut
HLS adaptive streaming with 4 quality profiles
Scheduling with Google Calendar, Slack, Discord integrations

Tech Stack: React 19, Express 5, PostgreSQL, Redis, FFmpeg, Bun, Kubernetes, ArgoCD

High-Level Design (HLD)

System Architecture

Weave follows a microservices architecture within a monorepo (Turborepo). Six services communicate via HTTP REST, WebSocket, and Redis-backed asynchronous job queues.

┌──────────────────────────────────────────────────────────────────────────┐
│                          CLIENT (React + Vite)                          │
│  Dashboard │ Live Meeting (Jitsi) │ Video Editor │ Recording Viewer      │
└────────────┬─────────────────────────────────────────────────────────────┘
             │ HTTPS                               │ WebSocket
             ▼                                     ▼
┌────────────────────────────┐    ┌──────────────────────────────┐
│    BACKEND (Express 5)     │    │   WS-RELAYER (Bun WebSocket) │
│  Port 3000                 │    │   Port 9093                  │
│  REST API ─ Auth           │    │  ─ Chat messaging            │
│  ─ Meetings ─ Recording    │    │  ─ Participant presence      │
│  ─ Editor ─ Notifications  │    │  ─ Recording state events    │
│  ─ GitHub ─ Google OAuth   │    │  ─ Typing indicators         │
└──────┬─────────────────────┘    └──────────┬───────────────────┘
       │                                     │
       ▼                                     ▼
┌──────────────────────────────────────────────────────────────────────┐
│                           INFRASTRUCTURE                             │
│  ┌──────────┐  ┌────────────────────┐  ┌──────────────────────────┐  │
│  │PostgreSQL│  │ Redis              │  │ S3-Compatible Storage    │  │
│  │(NeonDB)  │  │ ─ Job Queues (5)   │  │ (AWS S3 / GCS)          │  │
│  │Prisma    │  │ ─ Rate Limiting     │  │ ─ Encrypted chunks      │  │
│  │14 Models │  │ ─ Chat History     │  │ ─ Final recordings       │  │
│  │15 Enums  │  │ ─ CEK Storage     │  │ ─ HLS streams            │  │
│  └──────────┘  └────────────────────┘  │ ─ Editor assets          │  │
│                                         └──────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────┘
       │
       ┌──────────────────┬──────────────────────┐
       ▼                  ▼                      ▼
┌──────────────┐ ┌───────────────┐ ┌──────────────────────┐
│Merger-Worker │ │Editor-Worker  │ │   Transcoder          │
│(Bun + FFmpeg)│ │(Bun + FFmpeg) │ │(Bun + FFmpeg)         │
│              │ │              │ │                      │
│Decrypts &    │ │Renders video │ │Converts MP4 → HLS    │
│merges chunks │ │editor exports│ │360p/480p/720p/1080p  │
│→ per-user    │ │with effects, │ │+ poster + sprites    │
│videos → grid │ │transitions,  │ │+ VTT thumbnails     │
│video         │ │overlays      │ │                      │
└──────────────┘ └───────────────┘ └──────────────────────┘

Redis Queue Architecture

Five job queues power asynchronous processing. All workers use Redis Lists with BLPOP for blocking dequeue and RPUSH for enqueue.

Queue	Producer	Consumer	Purpose
`ProcessVideo`	Backend (on meeting end)	Merger-Worker	Decrypt & merge chunks
`TranscodeVideo`	Merger-Worker, Editor-Worker	Transcoder	HLS conversion
`EditorRender`	Backend (on export)	Editor-Worker	Render video exports
`Notifications`	All services	Backend	Deliver user notifications
`MeetingInvitations`	Backend	Backend	Send meeting invites

Deployment Architecture

Weave runs on Kubernetes managed via ArgoCD (GitOps). All services are deployed in the weave namespace.

                         Internet
                            │
                    ┌───────┴────────┐
                    │  NGINX Ingress │ (cert-manager TLS)
                    └───────┬────────┘
                            │
         ┌──────────────────┼──────────────────┐
         ▼                  ▼                  ▼
   weave.krishlabs.tech  api.weave...     wss.weave...
   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
   │  Frontend    │  │  Backend     │  │  WS-Relayer  │
   │  (React SPA) │  │  Express 5   │  │  Bun WS      │
   │  Pod: 1      │  │  Pod: 1      │  │  Pod: 1      │
   │  CPU: 300m   │  │  CPU: 500m   │  │  CPU: 300m   │
   │  RAM: 256Mi  │  │  RAM: 512Mi  │  │  RAM: 256Mi  │
   └──────────────┘  └──────────────┘  └──────────────┘

   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
   │Merger-Worker │  │Editor-Worker │  │  Transcoder  │
   │  Pod: 1      │  │  Pod: 1      │  │  Pod: 1      │
   │  CPU: 512m   │  │  CPU: 512m   │  │  CPU: 512m   │
   │  RAM: 1Gi    │  │  RAM: 1Gi    │  │  RAM: 1Gi    │
   │  Vol: 20Gi   │  │  Vol: 20Gi   │  │  Vol: 20Gi   │
   └──────────────┘  └──────────────┘  └──────────────┘

   ┌──────────────────┐
   │  Redis (in-cluster) │
   │  Pod: 1             │
   │  CPU: 100m, RAM: 128Mi │
   └──────────────────┘

External Dependencies:

NeonDB (PostgreSQL) — managed database on AWS via Neon
S3-compatible storage — production bucket on krishlabs.tech
Let's Encrypt — TLS certs via cert-manager

Core Data Flow: The Recording Pipeline

This is the heart of Weave's innovation:

1. MEETING START
   Client generates 256-bit Content Encryption Key (CEK)
   Fetches server's RSA-4096 public key
   Wraps CEK with RSA-OAEP-256
   Stores wrapped CEK → POST /keys/meeting/:id/wrapped-cek
   Redis stores it (7-day TTL)

2. EVERY 60 SECONDS (during meeting)
   Capture MediaStream → MediaRecorder → WebM chunk
   Generate 96-bit IV (deterministic: SHA-256 of userId:seqNum)
   Encrypt: AES-256-GCM(chunk, CEK, IV)
   Upload: POST /upload-chunk
     └─ Backend stores to S3 + upserts MediaChunk record

3. MEETING ENDS
   Backend finalizes → RPUSH "ProcessVideo" { meetingId }

4. MERGER WORKER (BLPOP "ProcessVideo")
   Download all chunks from S3 (organized by participant)
   Decrypt each chunk:
     ├─ Fetch wrapped CEK from Redis
     ├─ Unwrap with server RSA private key
     └─ AES-GCM-decrypt(ciphertext, CEK, IV, authTag)
   Per user: concatenate chunks → single MP4
   Upload per-user video → S3 (participants/{userId}/merged.mp4)
   Speaker analysis via FFmpeg silencedetect
   Composite grid layout → final grid video
   Upload final → S3 (final/meeting_grid_recording.mp4)
   RPUSH "TranscodeVideo" { meetingId, finalPath }

5. TRANSCODER (BLPOP "TranscodeVideo")
   Download final MP4
   Single-pass multi-profile encode:
     ├─ 360p (640x360, 800kbps)
     ├─ 480p (854x480, 1000kbps)
     ├─ 720p (1280x720, 2.8Mbps)
     └─ 1080p (1920x1080, 5Mbps)
   Generate master.m3u8 playlist
   Generate poster.jpg + sprites.jpg + thumbnails.vtt
   Upload HLS artifacts → S3
   Report READY → Backend

Low-Level Design (LLD)

1. Encryption Protocol

┌──────────────────────────────────────────────────────────────────┐
│                     Encryption Architecture                      │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  CEK (256-bit random) ──── RSA-OAEP-256 ────► Server Public Key │
│       │                                                          │
│       ▼                                                          │
│  Chunk ──► AES-256-GCM (CEK, IV) ──► Ciphertext + Auth Tag      │
│       │                                  │                       │
│       │                                  ▼                       │
│       │                           Upload to S3 + Metadata        │
│       │                                                          │
│  IV = first 12 bytes of SHA-256(userId:sequenceNumber)           │
│  Auth Tag = 128 bits (appended to ciphertext)                    │
│                                                                  │
│  Stored per chunk (MediaChunk table):                            │
│    - isEncrypted: true                                           │
│    - encryptionAlgorithm: "AES-GCM"                             │
│    - encryptionIv: base64(iv)                                    │
│    - encryptionTagBits: 128                                     │
│                                                                  │
│  Wrapped CEK stored in Redis:                                    │
│    Key: meeting:wrapped-cek:{meetingId}:{participantId}          │
│    TTL: 7 days                                                   │
└──────────────────────────────────────────────────────────────────┘

2. Database Schema (Core Models)

┌───────────────┐     ┌──────────────────┐     ┌──────────────────┐
│     User      │     │     Meeting      │     │  MediaChunk      │
├───────────────┤     ├──────────────────┤     ├──────────────────┤
│ id (PK)       │────>│ id (PK)          │────>│ id (PK)          │
│ email (UQ)    │     │ roomId (UQ)      │     │ meetingId (FK)   │
│ password      │     │ userId (FK)      │     │ uploaderUserId   │
│ googleId (UQ) │     │ passcode         │     │ sequenceNumber   │
│ githubToken   │     │ recordingState   │     │ bucketLink       │
│ tier          │     │ isEnded          │     │ isEncrypted      │
│ isVerified    │     │ startedAt        │     │ encryptionAlgorithm
│              │     │ endedAt          │     │ encryptionIv     │
└───────────────┘     └──────────────────┘     └──────────────────┘
       │                       │
       │                       │
       ▼                       ▼
┌───────────────┐     ┌──────────────────┐     ┌──────────────────┐
│ Notification  │     │FinalRecording    │     │ParticipantSource │
├───────────────┤     ├──────────────────┤     ├──────────────────┤
│ id (PK)       │     │ id (PK)          │     │ id (PK)          │
│ userId (FK)   │     │ meetingId (FK,UQ)│     │ meetingId (FK)   │
│ type (Enum)   │     │ videoLink        │     │ participantId    │
│ message       │     │ version          │     │ videoUrl         │
│ metadata (JSON)│     │ visibleToEmails[]│     │ durationMs       │
│ isRead        │     │ audioLink        │     │ fileSizeBytes    │
└───────────────┘     └──────────────────┘     └──────────────────┘

┌───────────────────────────────── Editor Domain ─────────────────────────────────┐
│                                                                                  │
│  ┌────────────────┐    ┌──────────────┐    ┌────────────────┐    ┌─────────────┐│
│  │ EditorProject  │───>│ EditorTrack  │───>│  EditorClip    │    │EditorAsset  ││
│  ├────────────────┤    ├──────────────┤    ├────────────────┤    ├─────────────┤│
│  │ id (PK)       │    │ id (PK)      │    │ id (PK)        │    │ id (PK)     ││
│  │ ownerId (FK)  │    │ projectId(FK)│    │ trackId (FK)   │    │ projectId   ││
│  │ meetingId (FK)│    │ type (Enum)  │    │ sourceAssetId  │    │ participantKey│
│  │ sourceMode    │    │ order (UQ)   │    │ timelineStartMs│    │ url          │
│  │ status        │    │ visible      │    │ durationMs     │    │ type (Enum)  │
│  │ durationMs    │    │ muted        │    │ sourceStartMs  │    │ waveformUrl  │
│  │ fps/width/hgt │    │ participantKey│   │ metadata(JSON) │    └─────────────┘
│  └────────────────┘    └──────────────┘    └────────────────┘                   │
│         │                                                                       │
│         ▼                                                                       │
│  ┌────────────────┐    ┌──────────────┐    ┌────────────────┐                   │
│  │ EditorOverlay  │    │ ExportJob    │    │  MulticamLayout│                   │
│  ├────────────────┤    ├──────────────┤    ├────────────────┤                   │
│  │ projectId (FK) │    │ projectId    │    │ projectId (FK) │                   │
│  │ type (Enum)    │    │ status (Enum)│    │ name           │                   │
│  │ content (JSON) │    │ progress     │    │ viewMode (Enum)│                   │
│  │ timelineStartMs│    │ outputUrl    │    │ rows/cols      │                   │
│  │ transform(JSON)│    │ error        │    │ segments[]     │                   │
│  │ style (JSON)   │    └──────────────┘    └────────────────┘                   │
│  │ animation (JSN)│                                                             │
│  └────────────────┘                                                             │
└──────────────────────────────────────────────────────────────────────────────────┘

Key Enums (15 total):

RecordingState: IDLE → RECORDING → UPLOADING → PROCESSING → READY | FAILED
ExportStatus: QUEUED → PROCESSING → DONE | FAILED
SourceMode: FINAL | MULTITRACK
UserTier: FREE | PRO | ENTERPRISE | ADMIN
ViewMode: GRID | SINGLE | PIP | CUSTOM

3. Video Editor Architecture (LLD)

┌────────────────────────────────────────────────────────────────────────────┐
│                        Editor Architecture (Frontend)                       │
│                                                                            │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌───────────────────┐ │
│  │ useEditor   │  │usePlayback  │  │useTrack     │  │useEditorHistory   │ │
│  │ Project     │  │State        │  │Operations   │  │(Undo/Redo, 100    │ │
│  │(Auto-save   │  │(Play/Pause  │  │(CRUD clips, │  │ snapshots)        │ │
│  │ 1s debounce)│  │ Seek,       │  │ split,      │  │                   │ │
│  │             │  │ Source↔Time)│  │ transitions)│  │                   │ │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └───────────────────┘ │
│         └────────────────┼────────────────┘                                │
│                          ▼                                                  │
│  ┌──────────────────────────────────────────────────────────────────┐      │
│  │                         Editor.tsx                               │      │
│  │  ┌─────────────┐  ┌──────────────┐  ┌─────────────────────────┐ │      │
│  │  │ Timeline    │  │ CanvasPlayer │  │    EditorPanel          │ │      │
│  │  │ (Horizontal │  │ (request     │  │  ┌─────────────────┐   │ │      │
│  │  │  scrollable │  │  Animation   │  │  │ Tabs: Text,     │   │ │      │
│  │  │  tracks)    │  │  Frame loop) │  │  │ Transitions,   │   │ │      │
│  │  │             │  │              │  │  │ Presets,       │   │ │      │
│  │  │ Ruler       │  │ <video> →    │  │  │ Effects,       │   │ │      │
│  │  │ Track lanes │  │ <canvas>     │  │  │ Transform,     │   │ │      │
│  │  │ Clip blocks │  │  compositing │  │  │ Multicam       │   │ │      │
│  │  │ Transition  │  │  + overlays  │  │  └─────────────────┘   │ │      │
│  │  │ indicators  │  └──────────────┘  └─────────────────────────┘ │      │
│  │  └─────────────┘                                                │      │
│  └──────────────────────────────────────────────────────────────────┘      │
│                                                                            │
│  Canvas Rendering Pipeline (useCanvasVideo + RenderLoop):                  │
│    requestAnimationFrame                                                   │
│      ├─ Read current video frame from hidden <video> element              │
│      ├─ Apply transform (stretch, offset, trim)                           │
│      ├─ Render transition between clips (xfade, slide, wipe, etc.)       │
│      ├─ Composite overlays (text with font/shadow/animation)              │
│      └─ Draw to visible <canvas>                                          │
└────────────────────────────────────────────────────────────────────────────┘

Canvas Rendering Pipeline:

requestAnimationFrame
  ├─ Read current frame from hidden <video> element
  ├─ Apply transform (stretch, offset, trim enforcement)
  ├─ Compute active transition between clips
  │    └─ Use TransitionRenderer for 33+ types (fade, slide, wipe, blur, zoom, cube, etc.)
  ├─ Composite overlays (TEXT type with animations: fade, slide, typewriter, bounce)
  └─ Draw to visible <canvas>

Editor Worker (FFmpeg) Render Pipeline:

processRenderJob()
  ├─ Collect render clips from project data
  ├─ Download source assets from S3 (content-addressable cache)
  ├─ For each clip:
  │    ├─ Apply trim + scale
  │    ├─ Apply effects (blur, color grade, chroma key, speed ramp)
  │    ├─ Apply preset (shake, glitch, VHS, cinematic-bars)
  │    └─ Generate ffmpeg filter graph
  ├─ Concatenate clips (with xfade transitions)
  ├─ Burn text overlays (drawtext with styling)
  ├─ Mix audio (volume ducking, adelay, amix)
  ├─ Upload to S3
  ├─ Update DB (ExportJob → DONE)
  └─ RPUSH "TranscodeVideo"

4. Multicam Architecture (V2 Design)

Multicam is Weave's V2 feature enabling true participant-level multi-camera editing:

┌─────────────────────────────────────────────────────────────────────────┐
│                         Multicam Pipeline                               │
│                                                                         │
│  Meeting Recording (raw chunks)                                         │
│         │                                                               │
│         ▼                                                               │
│  Merger Worker:                                                          │
│    ├─ Reconstruct per-participant MP4s from chunks                      │
│    ├─ Upload to: participants/{userId}/merged.mp4                       │
│    ├─ Speaker Analysis:                                                 │
│    │    ├─ ffmpeg silencedetect per participant                         │
│    │    ├─ Cross-reference energy peaks every 500ms window             │
│    │    └─ Store SpeakerTimeline records                                │
│    └─ Also produce standard grid video (backward compatible)            │
│                                                                         │
│  POST /api/v1/multicam/init                                             │
│    ├─ Create EditorProject with sourceMode = MULTITRACK                 │
│    ├─ Seed N video tracks (one per participant)                         │
│    ├─ Create ParticipantSource, MulticamLayout, Framing, Priority       │
│    └─ Return projectId                                                  │
│                                                                         │
│  Frontend Editor (Multicam mode)                                        │
│    ├─ SpeakerLane: color-coded who-spoke-when bars                      │
│    ├─ Program/Cut track: user's camera switch decisions                 │
│    ├─ Participant tracks: per-person video tracks with hide/toggle      │
│    ├─ PiP/Split/Grid layout presets                                    │
│    ├─ Reframe handles: per-participant crop + zoom                      │
│    ├─ Auto-cut suggestions from speaker analysis                       │
│    └─ Camera Priority Panel: drag-sort priority                         │
│                                                                         │
│  Editor Worker (multicam render):                                       │
│    ├─ Resolve program segments (user cuts or auto-follow speaker)       │
│    ├─ For each segment:                                                 │
│    │    ├─ Single: crop+scale active speaker fullscreen                │
│    │    ├─ PiP: overlay inset thumbnail on scaled main                 │
│    │    ├─ Split: hstack side-by-side (50/50 or 70/30)                │
│    │    └─ Grid: xstack N-up grid layout                               │
│    ├─ Burn speaker labels (drawtext)                                   │
│    ├─ Replace missing sources with placeholder (color + drawtext)      │
│    ├─ Concatenate segments + apply overlays + mix audio               │
│    └─ Promote + queue transcode                                        │
└─────────────────────────────────────────────────────────────────────────┘

5. FFmpeg Filter Graph Examples

Single clip with effects:

ffmpeg -i input.mp4 -filter_complex "
  [0:v]trim=start=10:end=20,setpts=PTS-STARTPTS,
       scale=1920:1080,
       eq=brightness=0.1:contrast=1.2:saturation=1.1,
       gblur=sigma=2[v];
  [0:a]atrim=start=10:end=20,asetpts=PTS-STARTPTS[a]"
-map [v] -map [a] output.mp4

PiP layout (multicam):

ffmpeg -i main.mp4 -i pip.mp4 -filter_complex "
  [0:v]crop=iw*1:ih*1,scale=1920:1080[main];
  [1:v]crop=iw*0.5:ih*0.5:iw*0.25:0,scale=480:270[pip];
  [main][pip]overlay=W-w-20:H-h-20,
       drawtext=text='Speaker':x=100:y=H-60:fontsize=24:fontcolor=white[out]"
-map [out] -map 0:a -map 1:a output.mp4

Grid layout (2x2):

ffmpeg -i a.mp4 -i b.mp4 -i c.mp4 -i d.mp4 -filter_complex "
  [0:v]scale=960:540[0v]; [1:v]scale=960:540[1v];
  [2:v]scale=960:540[2v]; [3:v]scale=960:540[3v];
  [0v][1v]hstack=inputs=2[row1];
  [2v][3v]hstack=inputs=2[row2];
  [row1][row2]vstack=inputs=2,
  amix=inputs=4"
output.mp4

6. API Endpoints (Key Routes)

Authentication
  POST /api/v1/user/signup                    # Register
  POST /api/v1/user/login                     # Login
  POST /api/v1/user/verify-email              # Verify 6-digit code
  GET  /api/v1/user/me                        # Current user

Meetings
  POST /api/v1/meeting/create                 # Create with passcode
  POST /api/v1/meeting/join/:id               # Join by roomId
  POST /api/v1/meeting/end/:id                # Host end meeting
  POST /api/v1/meeting/create/schedule        # Schedule meeting
  GET  /api/v1/meeting/get/:id                # Meeting details

Recording
  POST /api/v1/upload-chunk                   # Upload encrypted chunk
  POST /api/v1/recording/start/:id            # Host start recording
  POST /api/v1/recording/stop/:id             # Host stop recording
  GET  /api/v1/recording/status/:id           # Poll recording state
  GET  /api/v1/recording/page/:id             # Full recording page

Editor
  POST /api/v1/editor/projects                # Create editor project
  GET  /api/v1/editor/projects/:id            # Get project with tracks
  PUT  /api/v1/editor/projects/:id            # Save project state
  POST /api/v1/editor/projects/:id/exports    # Queue export job
  GET  /api/v1/editor/exports/:jobId/stream   # SSE export progress

Multicam
  POST /api/v1/multicam/init                  # Create multicam project
  GET  /api/v1/multicam/projects/:id          # Full multicam manifest
  PUT  /api/v1/multicam/projects/:id/framings # Update crop/zoom
  PUT  /api/v1/multicam/projects/:id/priorities# Camera priority
  POST /api/v1/multicam/projects/:id/auto-cut # Generate cuts

Worker (internal)
  POST /api/v1/worker/recording-status/:id    # Worker → Backend callback

Encryption
  GET  /api/v1/keys/public                    # Server RSA public key (JWK)
  POST /api/v1/keys/meeting/:id/wrapped-cek   # Store wrapped CEK

Integrations
  GET  /api/v1/google/auth/url                # Google OAuth URL
  GET  /api/v1/github                         # GitHub OAuth redirect
  POST /api/v1/github/create/issue            # Create GitHub issue

7. Key API Contracts

Upload Chunk (the most critical endpoint):

POST /api/v1/upload-chunk
Headers: Authorization: Bearer <jwt>
Body: multipart/form-data
  - file: binary (min 48 bytes)
  - meetingId: string
  - participantId: string
  - sequenceNumber: number
  - startedAt: ISO datetime
  - durationMs: number
  - sourceMimeType: string
  - encryptionAlgorithm?: "AES-GCM"
  - encryptionIv?: string (base64)
  - encryptionTagBits?: 128

Response: 201 { id, bucketLink }
Rate Limit: 600 req/min per user

Worker Recording Status (inter-service):

POST /api/v1/worker/recording-status/:meetingId
Headers: x-worker-token: <worker-service-jwt>
Body: {
  status: "PROCESSING" | "READY" | "FAILED",
  finalPath?: string,
  version?: string
}

On READY: updates Meeting.recordingState, creates FinalRecording,
          sends RECORDING_READY notification
On FAILED: sets recordingState to FAILED, sends RECORDING_FAILED notification

Design Decisions & Tradeoffs

Decision	Rationale
Local recording in chunks	Eliminates quality loss from bad internet; enables E2E encryption
AES-256-GCM per chunk	Authenticated encryption prevents tampering; deterministic IV avoids nonce reuse
RSA-OAEP key wrapping	Only the server can unwrap CEKs; clients never see the private key
Redis Lists for queues	Simple, reliable, no extra dependency (compared to Bull/SQS)
Per-participant video reconstruction	Enables true multicam editing from raw sources instead of merged grid
FFmpeg for all video processing	Battle-tested, supports every filter we need, static binaries for portability
Single-pass multi-profile encode	Scales to 4 HLS profiles in one FFmpeg pass instead of 4 sequential encodes
Canvas-based editor preview	Full control over rendering pipeline; supports effects/transitions/overlays in real-time

Conclusion

Weave demonstrates how to build a production-grade video conferencing platform with a focus on recording quality and post-production editing. The key architectural takeaways:

Client-side encryption before upload ensures privacy even from the platform provider
Chunk-based recording decouples recording quality from network quality
Redis-backed job queues enable reliable async processing of CPU-intensive video tasks
Per-participant source management enables powerful multicam editing scenarios
FFmpeg as a service provides a flexible video processing pipeline without custom C++ code.

Weave is open source. GitHub Repository

Building QuantNest: A Workflow Engine for Automated Trading

Krish Anand — Tue, 21 Jul 2026 06:55:22 +0000

The One-Line Hook

QuantNest is a drag-and-drop workflow engine where non-programmers wire up trading strategies as directed graphs, and a poll-based executor evaluates triggers, routes through conditional branches, and executes broker/notification actions — all without writing a single line of code.

The hard problem wasn't the workflow execution, or the visual builder, or even the AI integration. It was making all three work together reliably under the constraint that trading actions have financial consequences and exactly-once execution matters.

Constraints & Requirements

I started with a few hard requirements:

No persistent connection to the database. The executor polls on an interval. This keeps the architecture simple — no WebSocket server, no long-lived cursor, no replica-set tailing. If the executor crashes, it just restarts and picks up on the next poll cycle.
Exactly-once semantics for trade actions. If the executor fires a buy order, crashes after the broker confirms but before persisting the result, and restarts — it should not buy again. This ruled out naive at-least-once polling.
Conditional branching must be user-comprehensible. Users need to see why a particular branch was taken. Every execution must be traceable — trigger evaluation, branch decision, node status, final outcome.
Token auth that survives concurrent requests. The frontend SPA makes multiple simultaneous API calls. If two 401s race and both try to refresh the token, only one should succeed, and the other should reuse the result.
Model-agnostic AI. Users bring their own API keys. The platform should route to Gemini, OpenAI, or Anthropic without caring which one is configured.

These constraints shaped every major design decision.

Architecture

The executor is the heart of the system. It runs an infinite loop:

wait 2000ms + backoff
  → fetch active workflows from MongoDB
  → for each, evaluate trigger condition
  → if triggered, lock workflow (Redis SET NX PX 5000)
  → execute graph recursively
  → persist execution trace
  → release lock

The backoff is intentionally linear (+250ms per empty poll, capped at 10s). Exponential felt wrong here — you want gradual backoff during quiet periods but fast recovery when conditions change. A trader's price trigger at 2s resolution needs to catch the breakout, not be sleeping in a 30-second backoff.

Key Design Decisions (and the tradeoffs I wrestled with)

1. Poll-based vs Event-driven

This was the first real decision. Event-driven (change streams, WebSocket, push) gives lower latency. But it adds a lot of complexity — reconnection logic, at-least-once delivery guarantees, ordering concerns.

Why I chose polling: Simplicity wins for an MVP. The poll loop is 63 lines of code. It handles crashes trivially (restart and re-poll). The linear backoff means quiet periods don't waste CPU, but active periods get fast response.

The tradeoff: Minimum trigger latency is 2 seconds. For a 1-minute candle strategy this is irrelevant. For a tick-level scalper it's unacceptable. At scale I'd add a push channel for time-sensitive workflows alongside the poll loop.

What I didn't expect: The empty-poll backoff interacts badly with workflows that trigger rarely. A workflow that fires once a day sees the poll interval drift to 10s after ~30 empty cycles. The fix was resetting the backoff counter after the first successful execution of the day, not on every poll cycle. I caught this when a user's market-open trigger fired 8 seconds late.

2. Token Rotation with Family Tracking

The auth design: 15-minute JWT access tokens + 7-day refresh tokens stored as SHA-256 hashes in MongoDB. Each refresh token has a familyId. When rotating, the old token is revoked and a new one is created in the same family. If a revoked token is presented, the entire family is revoked — this detects stolen token replay.

The frontend has a semaphore-based queue for concurrent refresh:

isRefreshing stops 401 from creating new refresh calls
  → if already refreshing, queue the pending request
  → on success, replay the queue
  → on failure, clear auth and redirect to login

Why I chose this: Because race conditions during token refresh are a real problem in SPAs. Without the queue, multiple failed requests cause cascading refreshes that lock out the user.

The tradeoff: The queue introduces memory pressure if many requests arrive while refresh is in-flight. In practice, this doesn't happen — the refresh window is ~200ms locally, and most SPAs don't fire 100 requests in that window.

What broke in production: The first version didn't have the queue. Two parallel API calls would both see 401, both try to refresh, the first would succeed, the second would fail because the first refresh rotated the token invalidating the second. The user would get logged out from a perfectly valid session. The queue + _retry flag fixed this, but it took two deployment cycles to get right. The lesson: always assume concurrent requests will race, even on a single-threaded browser event loop.

3. Conditional Branching as Source Handles

Nodes with conditions (conditional-trigger, if, recheck) expose two output handles: true and false. Edges connected to the true handle are followed when the condition evaluates to true, and vice versa.

The executor resolves branches at runtime:

function resolveConditionalEdges({ sourceNode, outgoingEdges, evaluatedCondition }) {
  return outgoingEdges.filter(edge => {
    if (edge.sourceHandle === "true") return evaluatedCondition === true;
    if (edge.sourceHandle === "false") return evaluatedCondition === false;
    return true; // non-conditional edges pass through
  });
}

Why I chose this: It maps directly to the visual representation. Users see two labeled ports on the node. They drag edges from the port that matches their intent. No complex rule editor, no expression language to learn.

The tradeoff: This limits conditions to binary (true/false). Multi-way branching requires chaining if nodes. For trading strategies this is rarely an issue — most branching is "if condition met, buy; else wait." But for general-purpose automation it would be limiting.

What I'd do differently: Store the condition expression in the edge metadata instead of the source handle string. This would allow future extension to switch-case patterns without changing the node model.

4. Redis Locks for Execution Cooldown

Every workflow execution acquires a Redis lock with 5-second TTL:

SET lock:exec:<workflowId> <instanceId> NX PX 5000

If the lock can't be acquired, the execution is skipped. This prevents the same workflow from being evaluated by two poll cycles simultaneously (e.g., if a trigger evaluation takes longer than the poll interval).

Why I chose this over MongoDB atomic updates: Redis locks are cheaper (in-memory vs disk write) and have natural TTL expiry. If the executor crashes mid-execution, the lock self-releases in 5 seconds. MongoDB would require a manual cleanup job or a TTL index on a lock document.

The tradeoff: Distributed locks require all instances to agree on the Redis instance. If Redis goes down, all executions skip (fail-safe, which is correct for trading). Adding a second Redis for high availability would double the infra. For a single-instance deployment this is fine.

What bit me: The lock release used GETDEL with ownership verification — you can only release a lock you own. But a slow GC pause on the executor could cause the lock to expire, then get acquired by a second instance, then the first instance resumes and releases the second instance's lock. The fix: locks should be treated as advisory, not authoritative. The execution checks the lock state at the start but doesn't enforce it during the run. Double-execution is prevented by idempotency keys, not locks.

5. AI Provider Strategy Pattern

The AI builder accepts natural language and produces structured workflow graphs. Three providers implement the same interface:

interface StrategyPlannerProvider {
  provider: string;
  models: AiModelDescriptor[];
  generatePlan(input, prompt): Promise<StrategyBuilderResponse>;
}

A resolver picks the right provider based on the user's model selection:

function resolvePlannerProvider(providers, requestedModel) {
  // finds the provider that owns the requested model
  // falls back to a default if no match
}

Why I chose this: Users bring their own API keys. Some prefer OpenAI, some Gemini, some Claude. The strategy pattern keeps the routing logic in one place. Adding a new provider is implementing one interface and registering it in the array.

The tradeoff: Each provider returns JSON in slightly different formats. The response parsing (Zod validation) has to be permissive enough to handle variance but strict enough to reject malformed graphs. A single provider with a well-defined output schema would be simpler but doesn't let users choose.

What surprised me: Gemini (gemini-2.5-flash) is consistently 2-3x faster than Claude Opus for the same prompt. The quality difference for simple strategy generation is negligible. The strategy pattern makes this optimization invisible to the user — they pick a model, and the routing happens transparently.

Error Handling by the Numbers

One of the most boring but important parts of the system: every API endpoint has explicit error paths. I counted them while writing this post:

121 res.status(4xx/5xx) calls across 6 route files
11 Mongoose models with 9 indexes
16 non-retryable error keywords that prevent infinite retry loops (auth errors, validation errors, missing configuration)
3 error boundary layers: Zod input validation, service-level errors, catch-all 500s

The pattern is consistent:

try {
  const parsed = SomeSchema.safeParse(req.body);
  if (!parsed.success) { res.status(400).json(...); return; }
  const result = await someOperation(parsed.data);
  res.status(200).json(result);
} catch (error) {
  if (isKnownError(error)) { res.status(error.statusCode).json(...); return; }
  console.error(error);
  res.status(500).json({ message: "Internal server error" });
}

Every route follows this. It's repetitive but it means no unhandled rejection crashes the server, and every error returns a structured response.

Benchmarks (Real Numbers, Not Marketing)

I ran these against the running system with Docker MongoDB + Redis on a Mac ARM laptop:

Metric	p50	p95
API request (no DB)	0.7ms	1.8ms
Burst (50 concurrent)	1.9ms	17ms
Signin (bcrypt + JWT)	89ms	104ms
Concurrent signins (1000 users)	8.4s	14.6s
Redis SET	3.7ms	5.3ms
Redis GET	3.5ms	4.1ms

The signin latency is dominated by bcrypt (cost factor 10). Under 1000 concurrent requests, bcrypt serializes on the CPU and latency climbs to 8 seconds. The bottleneck is intentional security, not the application. Switching to Argon2 or reducing the cost factor would improve throughput at the expense of password cracking resistance.

The API throughput (non-DB routes) is ~1000 req/s before rate limiting kicks in. The limiting factor is the event loop, not the database.

What Would I Do Differently at Scale?

1. CDC Instead of Polling

At 10,000+ active workflows, polling every 2 seconds becomes wasteful. I'd add MongoDB Change Streams for real-time trigger evaluation, falling back to polling for cold-start recovery. The poll loop would shift to a "dead letter" role — catch workflows that change streams missed.

2. Shard Workflows by Trigger Type

Price triggers need sub-second evaluation. Timer triggers are fine with 5-second resolution. Report-generation triggers can wait 30 seconds. Currently all workflows share one poll interval. Sharding by trigger type would let each poller run at its optimal frequency.

3. Replace bcrypt with Argon2id and Add a Session Cache

bcrypt at cost 10 gives 90ms per comparison. Under 1000 concurrent signins, this becomes 8 seconds of wall-clock time. Argon2id is hardware-resistant and faster on modern CPUs. Combined with a Redis session cache (O(1) lookup after first authentication), the majority of requests would bypass the hash entirely.

Currently there's no session cache — every authenticated request verifies the JWT signature (fast, ~1µs), but token refresh hits MongoDB with a findOne({tokenHash}) which is O(log n). Adding redisSet("session:<tokenHash>", userData, 3600) during token creation would make refreshes O(1) and reduce DB load.

4. Formalize the Circuit Breaker

Right now, consecutive failure thresholds (3 failures → warn, 5 failures → pause) are hardcoded in the execution service. I'd extract this into a formal circuit breaker with half-open state, configurable thresholds per action type, and exponential reset timeouts. Trading actions should have tighter thresholds than notification actions.

5. Webhook Gateway

The system currently has no webhook endpoint. For real-time broker callbacks (Zerodha order fills, Groww position updates), a webhook gateway with Redis-backed idempotency keys would replace the current polling-based state checking. The idempotency middleware already exists — it just needs a route to attach to.

What I Learned

Polling is underrated. Everyone reaches for WebSockets and event-driven architecture. A well-tuned poll loop with linear backoff handles 90% of use cases with 10% of the complexity.
Rate limiters are the first thing that breaks in benchmarks. I spent more time fighting express-rate-limit during load testing than writing the actual benchmark scripts. Plan your rate limit strategy before you need it.
Bcrypt doesn't scale. 1000 concurrent signins on a single core brings the server to its knees. If you expect high auth throughput, cache sessions aggressively or use a faster hash.
Family-based token rotation catches real attacks. In testing, a revoked token was presented within minutes of rotation. The family revocation killed it. Without family tracking, a stolen refresh token would stay valid until the user signs out.
The 61µs AI pipeline overhead is a rounding error. The actual latency is 100% determined by the AI provider. Don't optimize your prompt building pipeline — optimize your model selection.

Check it out: QuantNest
Found a bug or have an idea? Open an issue.

How I Built an AI Interview Platform That Survives Redis Outages

Krish Anand — Mon, 20 Jul 2026 12:38:18 +0000

Real‑time AI voice interviews and 100 % availability even when Redis, the email provider, or the AI itself goes down.

The One‑Line Hook

Evalio runs live AI‑powered voice interviews that adapt to the candidate, remember every session, and score across six dimensions — all while the backend is designed to never return a 500, no matter which dependency fails.

Constraints That Shaped Every Tradeoff

Before I wrote a single line of business logic, I locked in four non‑negotiables:

Constraint	Why it mattered
Real‑time audio latency < 2 s	A voice interview with lag feels broken. Candidates leave.
100 % availability under dependency failure	Users trust me with their practice time. Losing a session because an email API errored is a betrayal of that trust.
Ship fast, alone	I'm a single developer. I can't afford Kafka clusters, service meshes, or six microservices. Every abstraction must earn its keep.
End‑to‑end type safety	No `undefined is not a function` at 2 AM because the DB schema and the frontend types drifted apart. The compiler catches everything.

Architecture (The 30‑Second Tour)

Two servers, one monorepo.

Browser → nginx
            ├── HTTP  :3000  (Elysia)  → Auth, CRUD, Evaluation
            └── WS    :8080  (ws)      → Audio stream, Gemini relay
                                              → Gemini 2.5 Flash Live API
Redis   → Cache, Queue, Rate‑limiting
Postgres → Sessions, Turns, Users, Resumes
Resend  → Email notifications

Why two servers instead of one? Elysia supports WebSocket on the same port. I deliberately separated them because:

HTTP requests are short (milliseconds). WS connections live 30–60 minutes. A traffic spike on one shouldn't starve the other.
They scale independently. When the user base grows, the WS server needs more memory per connection; the HTTP server needs more CPU. Different profiles, different scaling.

The tradeoff is operational complexity — two ports, two health checks, two services in the Kubernetes manifest. Worth it.

Key Design Decisions

This is the heart of the article. Every choice I made was a tradeoff. Here's what I chose and why.

1. Redis over PostgreSQL for the Queue

Why: Real‑time interviews need a queue. When all 4 concurrent slots are full, the next candidate waits and sees their position update live. Redis sorted sets give me O(log N) push/pop and O(1) position lookups. The position is pushed to the waiting client via WebSocket — instant feedback, no polling.

Tradeoff: Redis is in‑memory and stateful. If it restarts, the queue vanishes. PostgreSQL would survive a restart but its pub/sub model adds latency and polling complexity.

Mitigation that saved me: The queue isn't essential for correctness — it's a UX nicety. When Redis fails, dequeueNext() returns null, getPosition() returns 0, and the system treats every session as instantly ready. No candidate is blocked by a queue outage. This isn't a hack — it's a deliberate design: a queue that causes errors is worse than no queue at all.

2. Circuit Breaker for Cache (50 Lines, 100 % Availability)

The cache middleware wraps route handlers with get/set Redis. If Redis is slow or down, every request blocks and eventually 500s. That's unacceptable.

The fix is a textbook circuit breaker living in 50 lines at apps/backend/src/lib/cache.ts:

3 failures → circuit OPEN → all cache ops return null → DB fallback
15 s later  → circuit HALF‑OPEN → one probe request
Probe succeeds → circuit CLOSED → caching resumes
Probe fails    → back to OPEN, wait another 15 s

The mistake I almost made: The original isReady() method didn't delegate to canAttempt(). When the circuit was open, it never probed — the system stayed degraded forever. Found it during benchmark testing. A bug that would have looked like a design failure in production.

Result verified by benchmarks: During a simulated Redis outage, the API maintained 100 % availability with no error rate increase. The only cost was slightly higher DB load (our queries average 1.70 ms, so even direct DB hits are fast).

3. Graceful Degradation at Every Layer

Three independent failure modes, three different recovery patterns:

Component	Fails How	Fallback	Recovery
Redis	Timeout / connection refused	Cache returns null → DB query	15 s circuit breaker probe
Email (Resend)	5xx / network error	Write to `PendingEmail` table	Exponential backoff: 5 s → 25 s → 125 s
Gemini AI	API error	Mark session FAILED, save partial progress	Candidate retries manually

The pattern is consistent: never crash, never lose data, always have a forward path.

Cache fallback: The cached() middleware catches Redis errors, returns null, and the handler queries PostgreSQL directly. The caller never sees a failure.
Email buffer: If Resend is down, the email is inserted into a PendingEmail table. A background job (flushPendingEmails) picks it up later with exponential backoff. 100 % delivery rate guaranteed, even during email provider outages.
Session preservation: If Gemini errors mid‑interview, the session is marked FAILED but all turns and scores are saved. The candidate picks up where they left off.

4. End‑to‑End Types: Prisma → Elysia → Eden → React

This is the single biggest productivity win for a solo developer.

Prisma schema → TypeScript types
     ↓
Elysia route  → uses Prisma types in request/response
     ↓
Eden Treaty   → auto‑generates type‑safe client
     ↓
React page    → imports Eden client, gets full autocomplete

If I rename a field in the Prisma schema, the compiler catches every broken reference across all four packages before I even run the tests. No runtime surprises. No "why is this undefined" debugging sessions at midnight.

Tradeoff: Tight coupling between backend and frontend types. In a monorepo with exactly one frontend, this is a feature. If I ever need a public API for third‑party consumers, I'd split the contract into OpenAPI/Swagger.

5. Prompt Layering over Monolithic Prompts

The AI's system prompt is assembled dynamically from 10 independent layers:

Objective + Candidate History + Company Context
+ Role Context + Interview Style + Interaction Depth
+ Resume + GitHub + Job Description + Evaluation Dimensions

Why: A single 3000‑word system prompt is unmaintainable. You can't A/B test "Role" separately from "Style" when they're in one blob. With layers, I can tweak the roleContext.ts file and know exactly what changed.

Impact weighting (measured empirically):

Role context: ~60 % of the interview quality
Interview style: ~25 %
Company context: ~10 %
Depth level: ~5 %

Tradeoff: ~200 lines of assembly logic instead of a single string. Worth every line for debuggability.

6. Gemini 2.5 Flash over GPT‑4o for Voice

Why: Gemini's API natively supports bidirectional audio streaming. The browser mic → WebSocket → Gemini → audio response pipeline completes in ~500 ms. GPT‑4o requires a three‑stage pipeline (STT → LLM → TTS), which adds 1.5–2 s of latency.

Tradeoff: GPT‑4o gives better‑quality answers on complex technical questions. But in a voice interview, latency destroys the experience faster than imperfect answers. A 2‑second delay makes the AI feel disengaged; a 500 ms delay feels like a real person thinking.

Benchmarks That Validate the Design

Numbers are meaningless without context. Here's what each benchmark proves:

Database Performance

Query	Total Time	Scan Type
Interview list (user + date)	5.13 ms	Index Scan
Rate‑limit count (7‑day window)	0.93 ms	Index Scan
Score trend (last 5 sessions)	0.29 ms	Index Scan
Interview detail (with joins)	1.16 ms	Index Scan
Refresh‑token lookup	1.01 ms	Index Scan
Average	1.70 ms	—

What this proves: The composite indexes on InterviewSession(userId, createdAt) and (userId, status, createdAt) eliminated sequential scans. Without them, these queries would take 50–200 ms at 10k rows. Estimated improvement: 29–117×.

API Throughput

Concurrency	Throughput	Avg Latency	P95	Errors
10×	19,190 req/s	0.4 ms	1.2 ms	0 %
25×	19,355 req/s	0.9 ms	1.9 ms	0 %
50×	23,318 req/s	1.4 ms	5.0 ms	0 %
100×	16,262 req/s	3.9 ms	6.6 ms	0 %

What this proves: The system saturates around 50 concurrent connections on an M3 MacBook. Beyond that, throughput drops slightly due to Bun's event loop pressure. But 23 k req/s is well above any realistic load for a bootstrapped SaaS.

Circuit Breaker & Degradation

Circuit breaker: 3 failures → open → 15 s → half‑open → recovery. Verified end‑to‑end.
Degradation: Redis outage → 100 % API availability. Email outage → 0 % delivery loss.
Audio latency: ~500 ms end‑to‑end (estimate, measured locally without production network conditions).

What I'd Do Differently at Scale

The current design works for a solo‑dev bootstrapped product. If I woke up tomorrow with 10 000 concurrent users, here's what would break first and how I'd fix it:

1. Replace Redis Queue with Kafka (or PostgreSQL `SKIP LOCKED`)

Redis sorted sets work well until a node restarts mid‑interview and the queue state disappears. At scale:

Kafka: Durable, replayable, partition‑aware. Overkill today, necessary when queue state becomes a correctness requirement.
PostgreSQL SKIP LOCKED: Simpler, no new infrastructure, but polling adds latency for position updates.

2. Split the WebSocket Server into Its Own Autoscaling Group

Currently both servers live in one Kubernetes deployment. WS connections pin memory and CPU — an interview session consuming 200 MB for audio buffers shouldn't compete with HTTP requests for the same resources.

At scale: separate Deployment for evalio-backend-ws with its own HPA based on active connections, while the HTTP server scales on request rate.

3. CDN for Audio Response Caching

Every audio chunk from Gemini is streamed through the WS to the client. If I cached common responses (greetings, explanations) on a CDN, I could reduce Gemini API calls by an estimated 20–30 %.

The tricky part: audio responses are ephemeral and session‑specific. Only deterministic, non‑personalized chunks can be cached.

4. Shard by User ID

The current queue is a single sorted set. With 10 k concurrent users, ZRANGE operations on a set with millions of entries become noticeable. Sharding by userId % SHARD_COUNT would distribute load across N Redis instances.

5. Real Monitoring (Not Just Logs)

Today I rely on circuit breaker logs and manual health checks. At scale, I'd add:

Prometheus metrics for cache hit ratio, queue depth, circuit breaker state
Alerts for circuit‑breaker open events and email buffer growth
Tracing across the audio pipeline to pinpoint latency sources

Lessons Learned

A cache that 500s is worse than no cache. The circuit breaker is 50 lines of code that made Redis a non‑critical dependency instead of a single point of failure.
Graceful degradation isn't optional. Three fallback mechanisms — cache, queue, email — cover every external dependency. None of them are complex. All of them prevent user‑visible errors.
Type‑safety is a force multiplier for solo devs. The Prisma → Elysia → Eden pipeline caught dozens of refactoring mistakes before they reached production. I'd trade a few percentage points of runtime performance for compile‑time safety any day.
Benchmarks exposed a bug that would have been catastrophic. The isReady() → canAttempt() delegation bug was invisible during development. Only the benchmark's failure‑injection test revealed it. Always stress‑test your failure modes.

Built with Bun, Elysia, React 19, PostgreSQL, Redis, and Gemini 2.5 Flash. Deployed on Kubernetes via ArgoCD.

Check it out: Evalio

Found a bug or have an idea? Open an issue.