Courses › System Design › Question Breakdowns

Design Zoom (Video Conferencing)

Control vs. media plane, SFUs and simulcast, UDP and jitter buffers, cascading servers and fast failover.

Design a video conferencing service like Zoom: users join a meeting from any device and see and hear each other in real time, share their screen, and chat — from 1:1 calls to meetings of hundreds. It's a question about real-time media over UDP, SFUs vs. MCUs vs. peer-to-peer, adapting to bad networks, and routing participants to nearby media servers.

Requirements

Functional

  • Users can create and join meetings (link + passcode), with a host who can mute/remove participants
  • Participants send and receive audio and video in real time and can share their screen
  • Meetings support up to ~1,000 participants (most are small)
  • In-meeting chat and optional recording

Out of scope: webinars with 10k+ view-only attendees (discuss as an extension), calendar integration, transcription.

Non-functional

  • Low latency: mouth-to-ear under ~150–200ms; anything above ~400ms breaks conversation
  • Resilient to packet loss and jitter; degrade quality rather than freeze
  • Scale: ~300M daily meeting participants, millions of concurrent meetings
  • Highly available; a media server failure should drop a meeting for seconds at most
  • Secure: encrypted media; only invited people can join

[!TIP] Control plane vs. media plane Joining, authentication and meeting state are ordinary request/response (control plane). The audio/video itself is a continuous, latency-critical stream over UDP (media plane). They have different protocols, servers and scaling rules — draw them separately.

Capacity estimates

Core Entities

  • Meeting — ID, host, passcode, settings, scheduled time
  • Session — a live instance: assigned media server(s), participants, start time
  • Participant — user, device, role, streams published, connection quality

API

POST /v1/meetings   { "topic": "Weekly sync", "startTime": "...", "settings": {...} }   → { "meetingId": "812-555", "joinUrl": "..." }
POST /v1/meetings/{id}/join   { "passcode": "...", "device": "desktop" }
→ { "sessionToken": "...", "mediaServer": "sfu-us-east-1-17.example.com:8801", "iceServers": [...] }

# then: signaling over WebSocket (SDP offers/answers, mute, raise hand, layout)
# media: SRTP over UDP to the media server (TCP/TLS fallback)

High-Level Design

a = client "Participant A" @0,0
b = client "Participant B" @0,2
api = service "Meeting API\n(control plane)" @1,1
mdb = store "Meetings DB" @2,1
sig = service "Signaling\n(WebSocket)" @1,0
sfu1 = service "SFU (region 1)" @2,0
sfu2 = service "SFU (region 2)" @2,2
rec = service "Recording Workers" @3,0
store = blob "Recordings (S3)" @3,1
a -> api : join
b -> api
api -> mdb
a <-> sig
a <-> sfu1 : SRTP / UDP
b <-> sfu2 : SRTP / UDP
sfu1 <-> sfu2 : cascade
sfu1 -> rec
rec -> store
  • Join: the meeting API authenticates the participant and picks a media server close to them (or the one already hosting the meeting).
  • Signaling: a WebSocket carries session setup (codecs, ICE candidates) and controls (mute, layout).
  • Media: each participant sends their streams once to the SFU, which forwards them to other participants.
  • Large or global meetings: SFUs in different regions cascade — forwarding streams between each other — so everyone connects to a nearby server.

Deep Dives

1. Peer-to-peer, MCU or SFU?

The SFU is the standard answer: clients upload once, the server selectively forwards, and there's no transcoding latency or cost.

2. Adapting to each receiver's network

Different receivers have different bandwidth. Two techniques let the SFU send each one what it can handle without transcoding:

  • Simulcast: each sender uploads the same video at 2–3 resolutions (e.g. 180p, 360p, 720p); the SFU picks a layer per receiver.
  • SVC (scalable video coding): one stream with layers the SFU can drop.

The SFU also only forwards what's visible: in gallery view of 49 tiles, thumbnails at low resolution; the active speaker at high. Audio uses Opus with forward error correction; video tolerates loss via retransmission (NACK) and keyframe requests.

3. Why UDP

TCP's retransmission stalls the whole stream behind one lost packet (head-of-line blocking). For live media, a late packet is useless — better to skip it. Media runs over RTP/SRTP on UDP, with jitter buffers on receivers to smooth arrival times. Corporate firewalls that block UDP get a fallback over TCP/TLS 443 (higher latency).

4. Getting through NATs

Most clients sit behind NAT. With an SFU, clients only need to reach the server, which has a public IP — simpler than P2P. For P2P 1:1 calls, use ICE with STUN (discover the public address) and TURN relays when direct connection fails.

5. Placing meetings on servers

  • Route each participant to the nearest healthy SFU region (GeoDNS/anycast + latency probes).
  • A meeting lives on one SFU (or a cascade); a meeting registry maps meeting ID → SFU(s) so later joiners find it.
  • SFUs report load (bandwidth, CPU); the allocator places new meetings on servers with headroom.

[!WARNING] Failover in seconds, not minutes Media servers hold live state. When an SFU dies, clients detect missing media within a couple of seconds, ask the control plane for a new server, and re-join; the registry moves the meeting. Design the client reconnect path explicitly — it's what users experience as reliability.

6. Recording and large meetings

  • Recording: a recording bot joins as a hidden participant on the SFU, receives the streams, and composites/encodes them into a file in object storage (async — it can lag).
  • Webinars (10k+ viewers): most attendees only watch. Send them a composited stream via low-latency HLS/CDN (seconds of delay) instead of SFU slots.

7. Security

Media is encrypted with SRTP (keys exchanged via DTLS). For end-to-end encryption, keys are shared among participants and the SFU only forwards ciphertext — which rules out server-side recording and compositing. Meetings use unguessable IDs, passcodes and waiting rooms.

What's expected at each level

  • Mid-level: a control plane for meetings, WebSocket signaling, media through servers, UDP for media.
  • Senior: SFU vs. MCU vs. mesh, simulcast and visible-only forwarding, jitter buffers and loss handling, NAT traversal, routing participants to nearby servers.
  • Staff: cascading SFUs across regions, meeting placement and failover, webinar fan-out via CDN, end-to-end encryption trade-offs.