System design deep dive · HLD
Design Zoom (video conferencing): full high-level design.
Requirements, back-of-envelope capacity estimation, a high-level design diagram, a deeper deployment architecture diagram, sequence diagrams for call setup and recording, and an entity-relationship diagram for the data model - with the reasoning an interviewer expects behind every box and arrow.
1. Clarify requirements before drawing any box
Video conferencing lives or dies on one number: end-to-end media latency. Every architectural choice below is downstream of accepting that a video call is not a request/response system - it is a continuous, loss-tolerant, real-time stream that must never be routed through a slow path.
Functional requirements
Non-functional requirements
2. Back-of-the-envelope capacity estimation
These numbers are what rule out both peer-to-peer mesh and a fully-transcoding media server as the media routing approach, and drive how many media relay servers are needed globally.
| Metric | Assumption | Resulting estimate |
|---|---|---|
| Concurrent participants | 5 million concurrent participants at global peak | baseline for media relay and signaling capacity |
| Average meeting size | ~8 participants/meeting | ~625,000 concurrent meetings at peak |
| Per-participant uplink | ~1.5 Mbps video + ~64 Kbps audio | 5M × ~1.56 Mbps ≈ 7.8 Tbps aggregate ingress to the media layer |
| Per-participant downlink | Active speaker high-res (~1.5Mbps) + ~3 thumbnail streams (~200Kbps each) | ~2.1 Mbps/participant × 5M ≈ 10.5 Tbps aggregate egress (before larger-meeting fanout) |
| Total relay throughput | Ingress + egress combined, plus large-webinar fanout overhead | ~35-40 Tbps aggregate media relay bandwidth needed at peak globally |
| SFU fleet size | ~10 Gbps sustained relay capacity per media server | ~3,500-4,000 SFU nodes needed globally at peak, geographically distributed |
3. High-level design (HLD)
The HLD names the major components and separates the signaling path (control plane, can tolerate normal internet latency) from the media path (data plane, must be as close to the network as physically possible), without yet committing to region layout or cascading strategy for huge meetings.
What each box owns
Signaling service
A stateful, WebSocket-based control-plane service that exchanges SDP offers/answers and ICE candidates between participants and manages meeting membership (who's in, who's out, mute state). It never touches actual audio/video bytes - its only job is negotiating how and where media will flow before handing off to the SFU.
Meeting coordinator
Decides which SFU node (in which region) hosts a given meeting, typically the node closest to the meeting's creator with available capacity, and pins the entire meeting to that node (or a cascaded set of nodes for very large webinars) so all participants' media converges in one place rather than being split unpredictably.
SFU cluster (the media data plane)
Each participant sends one encrypted (DTLS-SRTP) upstream connection to their meeting's assigned SFU node and receives downstream streams from it. The SFU forwards encoded RTP packets - it does not decode, re-encode, or mix anything - selecting which simulcast layer (resolution/bitrate) to forward to each receiver based on that receiver's available bandwidth and whether the sender is currently the active speaker. This is the entire reason media routing scales: CPU cost per stream is packet-forwarding, not decode/encode.
Recording service and STUN/TURN
The recording service joins a meeting as a special subscribe-only participant of the SFU, receiving the same streams a viewer would, and a compositor mixes them into a single output file uploaded to object storage as the meeting progresses. STUN/TURN servers handle NAT traversal - STUN lets most participants connect directly or via a lightly-relayed path, while TURN is the fallback relay for the minority of participants behind symmetric NATs or restrictive firewalls that make direct connection impossible.
4. Detailed architecture diagram
The architecture diagram answers how meetings are placed on specific SFU nodes close to participants, how a meeting scales past one node's capacity, and how TURN's relay cost is kept to only the participants who actually need it - the details an interviewer checks once the HLD shape is accepted.
| Decision | Choice | Reasoning |
|---|---|---|
| Media routing topology | Selective Forwarding Unit (SFU), not mesh or MCU | Mesh multiplies uplink bandwidth by meeting size; an MCU that transcodes/mixes every stream multiplies CPU cost; an SFU forwards encoded packets, scaling with participant count in bandwidth only, which is the resource most abundant in a data center. |
| Meeting-to-node pinning | One meeting is pinned to one primary SFU node (or a small cascaded tree for huge webinars) | Keeps all of a meeting's participants' streams converging in one place, avoiding cross-node relay latency for the common case, while still allowing horizontal scale for outlier large meetings. |
| Simulcast over single-stream + server transcode | Each sender encodes 2-3 quality layers; the SFU picks which to forward per receiver | Avoids server-side transcoding entirely - the SFU just selects an already-encoded layer matching each receiver's bandwidth, trading a bit of sender-side CPU/bandwidth for a massive reduction in server compute cost. |
| TURN as fallback, not default | STUN-discovered direct/lightly-relayed path preferred; TURN used only when necessary | TURN relay consumes real server bandwidth per byte relayed and adds a hop of latency; reserving it for the ~10-15% of participants who truly need it (symmetric NAT) keeps relay costs proportional to actual necessity. |
5. Sequence diagrams for the two critical flows
A sequence diagram is where an interviewer checks whether a candidate separates the one-time signaling handshake from the continuous media stream that follows, and whether recording is treated as just another SFU subscriber rather than a special case.
5.1 Joining a meeting (signaling then media)
Step 2-3 only happen once, when the first participant joins - every subsequent joiner in steps that follow is simply told the same SFU node's address. The critical architectural point is step 7: once step 6's media connection is established directly between the client and the SFU, signaling is completely out of the loop - a signaling service outage after this point would not drop an already-connected call's audio or video.
5.2 Recording a meeting
Step 3 is deliberately the same join mechanism any regular participant uses, just flagged as subscribe-only with no upstream media of its own - the recorder is not a special protocol path, it's an ordinary SFU client. Step 6's periodic chunked upload (rather than one upload at the very end) is what protects against losing an entire meeting's recording if the compositor crashes mid-call: only the last unflushed chunk is at risk, not the whole session.
6. Entity-relationship (ER) diagram and schema
The data model here is deliberately small and metadata-only - the actual audio/video never touches a database - and has to answer: who is authorized to join, which SFU node holds a given participant's live connection, and how recording state is tracked.
Key modeling decisions
| Storage choice | Use when | Watch out for |
|---|---|---|
| Relational (Postgres) for meetings/participants/media_sessions | Volume is modest (millions of meetings, not billions of media packets) and simple joins (which participants are in this meeting) are the main access pattern. | media_sessions churns constantly (every reconnect); keep it lean and consider an in-memory store (Redis) if write volume becomes a bottleneck. |
| Object storage (S3) for recordings | Large binary files (hours of video) need durable, cheap, streaming-friendly storage. | Never modeled as a relational row's content - only a reference (URL, key) belongs in the database. |
7. Deep dives interviewers actually probe
Why an SFU instead of peer-to-peer mesh or a full MCU?
Mesh requires every participant to upload their stream N-1 times (once per other participant), which collapses past roughly 4-5 participants on typical home uplinks. An MCU decodes every incoming stream, composites/transcodes, and re-encodes outgoing streams - correctness is simple but CPU cost scales brutally and adds encode/decode latency. An SFU relays already-encoded packets without touching their content, so server cost scales with bandwidth (cheap and horizontally scalable) rather than CPU-per-stream, and adds minimal latency since nothing is decoded server-side.
How does simulcast actually decide what quality to send a given receiver?
Each sender encodes 2-3 independent quality layers simultaneously (e.g. 720p, 360p, 180p) at negligible extra CPU cost compared to transcoding. The SFU continuously monitors each receiver's downlink conditions via RTCP feedback (packet loss, estimated bandwidth) and simply switches which pre-encoded layer it forwards to that receiver - a participant on poor wifi gets the 180p layer of the active speaker without the sender needing to know or care, and without any server-side re-encoding.
How do you scale a single meeting past what one SFU node can handle?
For large webinars (hundreds to thousands of mostly-viewing attendees), a small tree of cascaded SFU nodes is used: one primary node receives the presenter's upload and a handful of secondary nodes each subscribe to it once and re-forward to their own pool of viewers. This turns "N viewers each pulling from one node" into a fan-out tree, bounding any single node's egress load regardless of total attendee count, at the cost of one extra relay hop of latency for viewers on secondary nodes.
Why is TURN needed at all if STUN already discovers a network path?
STUN helps a client discover its public-facing address so peers (or the SFU) can reach it directly, but it doesn't help when a NAT (commonly "symmetric NAT," found on some corporate/mobile networks) assigns a different external port for every destination, making direct connection impossible to establish reliably. TURN provides an actual relay server the client connects to instead, at the cost of consuming real server bandwidth for every byte of that participant's media - which is exactly why architecture keeps TURN as a fallback path rather than routing all media through it by default.
What happens if the compositor crashes mid-recording?
Because the recording pipeline uploads in ~60-second chunks rather than buffering the entire meeting and writing once at the end, a crash loses at most the last unflushed chunk - the recording service restarts, rejoins the SFU session (same mechanism as section 5.2), and resumes compositing/uploading, with the finalize step later stitching the chunk sequence into one playable file. This chunked design trades a small amount of continuous upload overhead for bounding data loss to seconds rather than risking an entire multi-hour recording.
Post a Comment
Add