Problem statement
Design the signaling and session-orchestration backbone for a real-time group video-conferencing product (think a widely used team-meeting app). Media itself flows peer-to-server over an SFU mesh; your job is the control plane that gets everyone into the right room, wires them to the right media server, and keeps the session coherent as people storm in and drop out.
Operating context. A meeting is a room that a host opens and up to a few hundred participants join from browsers and mobile clients spread across continents. At peak you run ~2M concurrently connected clients across ~150k live rooms; join/leave churn spikes hard on the hour (calendar boundaries) — tens of thousands of joins per second in a 60-second window. Most rooms are small (2–15), but a long tail of large rooms (hundreds) dominates fan-out cost. Signaling rides a persistent bidirectional channel (WebSocket); the SLO that matters is time-to-first-frame: from "click join" to seeing another participant's video, p99 < 2.5 s. Clients sit behind hostile NATs and corporate firewalls, so a meaningful fraction cannot reach a media server directly and must be relayed.
Out of scope. The media plane internals (codecs, jitter buffers, bandwidth estimation, simulcast layer selection), the actual SFU packet-forwarding logic, recording/transcription pipelines, end-to-end encryption key exchange, billing, and the calendar/invite product. Assume a separate team owns the media servers and exposes only a "reserve capacity / attach client" control API.
What to produce. A high-level architecture for the control plane covering: how a room is created and its lifecycle tracked; the signaling channel and how session state (who is in the room, their tracks, mute/hand-raise) is fanned out to participants; how a joining client is matched to an SFU instance (capacity- and geography-aware) and what happens when that SFU is full or fails; the ICE/TURN relay-fallback path for clients that can't reach the SFU directly; and how the whole thing absorbs the top-of-hour join storm without melting. Sketch the components and the join request flow end-to-end; checkpoints will probe SFU selection, churn handling, and failure blast radius.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design HLD
- Realtime Websocket
- Scaling Fanout
- Geo Sharding
- Infra Lb