Video calls - forwarding streams, not mixing them

Why this design

Zoom, Google Meet, Teams, Discord and every WebRTC product built on LiveKit, mediasoup or Janus make the same choice for group calls: a Selective Forwarding Unit in the middle that receives each participant's media once and forwards it, encrypted and undecoded, to everyone else. The interview question "design a video call for up to 50 people" is about knowing why - why not peer to peer, why not mix on the server - and then about the part that decides whether the call is any good: how the system notices that one person's network is bad and gives them less, without giving everyone less.

What you will learn

• Mesh vs MCU vs SFU in numbers: 16.5 Mbps of upload per person, a full transcode per layout, or a packet copy.
• Why signalling (who is in the room, SDP) and media (RTP over UDP) are different systems with different failure modes.
• ICE, STUN and TURN: why 10 to 15 percent of participants need a relay, and what TURN over TCP 443 costs.
• Simulcast: three encodings from one camera, and the 40 percent upload tax it charges the sender.
• Bandwidth estimation from transport-wide feedback, and how the SFU picks a layer per subscriber per second.
• Keyframes, NACK and PLI - and the keyframe storm one bad receiver can cause.
• The sizing: 2 million concurrent participants, 5 Tbps of SFU egress, about 900 SFU nodes, and a 150 ms mouth-to-ear budget.

How to read this board

1. Press play: eight steps follow Alice joining, sending one camera, and Bob and Carol receiving it at different qualities.
2. JOIN: Alice, signalling and the room state - none of this carries a single video packet.
3. SEND: the simulcast encoder, the uplink decision, and the TURN relay for networks that block UDP.
4. FORWARD: the SFU, the per-subscriber layer decision, the bandwidth estimator, keyframe control, the recorder, and the cascade link.
5. RECEIVE: Bob on fibre, Carol on 3G in red, the jitter buffer, and the remote SFU in another region.
6. Pages 1 to 6, then the DATA MODEL.

Ask these before drawing anything

• How big is a call? 2 to 12 is the common case; 50 interactive is the hard case; 1,000 watching is a broadcast, which is a different system (HLS or a fan-out tree of SFUs with view-only participants).
• Where are the participants? One region allows one SFU. Global calls need cascading, and the routing decision is per call.
• Is end-to-end encryption required? It is compatible with an SFU (it forwards opaque frames) and incompatible with server-side recording, transcription and mixing.
• Does the call need recording and live captions? Both are clients of the SFU, and both need to decode, which settles the encryption question for those calls.
• What devices? A phone on cellular cannot encode three 720p layers; the client must be able to offer two.
• What is the tolerated latency? Conversation breaks down above about 300 ms one way; the target is 150.

Functional

• Create and join a room by link; up to 50 interactive participants.
• Camera, microphone and screen share; mute and unmute; active-speaker detection.
• Each participant sees a grid or a speaker view; quality adapts per viewer.
• Calls survive a participant changing network (wifi to cellular) without leaving.
• Optional cloud recording and live captions.

Non-functional

• Mouth-to-ear latency under 150 ms p50 and 300 ms p95 within a region.
• Audio is never sacrificed for video: under congestion video degrades first, to a frozen tile if necessary.
• Join-to-first-frame under 2 s.
• 2 million concurrent participants at peak; 10 million meetings a day.
• An SFU node failure reconnects its calls within 5 s, automatically.

Out of scope

• Telephone dial-in (a SIP gateway is its own component).
• Large webinars over 50 interactive seats.
• Server-side noise suppression in end-to-end-encrypted calls - by construction the server never sees audio.