Backplane

Status: Draft Author: Ryan Nel Date: 2026-05-01

Problem

WebSocket events from Core can only reach the client connected to the pod that holds the session. There is no pub/sub backplane between Core pods. Any feature that uses WebSocket push — live recording, future notifications, live collaboration — is constrained to sticky-session load balancing. A pod restart drops all its sessions with no migration path. The engineering team discovered this constraint while designing the Meeting Recording bet, where it was documented as a design decision rather than solved inline.

Appetite

3–4 weeks. The problem is well-understood (Redis Pub/Sub or NATS between pods), but the solution touches Core's connection management, deployment topology, and every feature that uses WebSocket push. The risk is not the backplane itself — it's the integration surface across existing features.

Why Now

Meeting Recording is the first feature to rely heavily on WebSocket push. Sticky sessions work at current scale, but the constraint is now visible and documented. Solving it before a second real-time feature ships avoids retrofitting two features instead of one.