Design Zoom: Low-Latency Video Meetings for Millions of Participants

Listen

Listen. Users create and join meetings with audio, video and screen sharing, up to about a thousand interactive participants. There are gallery and speaker views, in-meeting chat and cloud recording. Non-functional: mouth-to-ear delay under about two hundred milliseconds, because beyond that conversation feels awkward. It must degrade gracefully on bad wifi, and participants are spread across the globe.

Scope out scheduling, calendar sync, billing and phone dial-in. Ask about the extremes. Are there webinars? Yes, with up to a hundred thousand view-only attendees, which is a different shape of problem from a meeting. Is end-to-end encryption required? As an optional mode. And what is the average meeting size? About five, which matters for the bandwidth math.

Ask scale

Ask about scale. At peak, ten million people are in meetings at once. With five per meeting, that is two million concurrent meetings. Meetings start on the hour, so joins are spiky: ten million joins across half an hour is several thousand a second, with sharp bursts at nine o'clock. Signalling traffic is tiny compared with media, so the real math is bandwidth.

Bandwidth. Each participant sends their camera at three qualities at once, about one point eight megabits a second in total. Each receives the active speaker in high quality plus four small tiles, roughly two megabits. Ten million participants times two megabits is twenty terabits a second of egress. If one media server pushes five to ten gigabits, that is thousands of servers spread over dozens of regions. Media servers, not databases, are the fleet to size.

peak: 10M concurrent
  participants
average meeting: 5 people
  → 2M concurrent meetings

joins: 10M over ~30 min at
  the top of the hour
  ≈ 5,000 joins/s, spiky

signalling is small; media
  is everything

send per participant (simulcast)
  720p 1.2 + 360p 0.4
  + 180p 0.15 ≈ 1.8 Mbps
receive: 1 speaker at 720p
  + 4 tiles at 180p ≈ 2 Mbps

server egress: 10M × 2 Mbps
  = 20 Tbps
one media server ≈ 5-10 Gbps
  → thousands of servers in
  dozens of regions

Define API

Define the API. Over REST: create a meeting, and join it, which returns a token, the media server to connect to, and the list of STUN and TURN servers. A signalling WebSocket carries session negotiation, the offer and answer describing codecs and streams, network candidates, plus roster updates like mute and raise hand. The media itself never goes through the API: it flows as encrypted RTP packets over UDP to a media server.

REST:
  POST /meetings → { id, pin }
  POST /meetings/{id}/join
    → { token, sfu_url,
        ice_servers }
signalling (WebSocket):
  offer / answer (SDP)
  ice-candidate
  roster, mute, raise-hand
media: RTP/SRTP over UDP
  to the SFU

Data model

The data model is small. Meetings and their settings in a relational database. Live room state, which media servers host this meeting, who is in it, and which streams each person publishes, lives in memory on the meeting service, backed by Redis so another instance can take over. A participant log stores join and leave times and quality statistics for analytics. Recordings point to files in object storage.

meetings (SQL): id, host,
  pin_hash, settings, status
live state (in memory / Redis):
  meeting_id → sfu list,
  participants, who is
  publishing which streams
participants log: joined_at,
  left_at, quality stats
recordings: meeting_id,
  object_key, duration

High-level design

Draw the high-level design, starting with a join. User A's client calls join and opens a signalling connection. The meeting service picks a media server for them: the nearest healthy one with capacity, here Mumbai. The client and the media server exchange an offer and answer through signalling, then user A starts sending audio and video directly to the media server over UDP. Signalling is control; media takes a separate, faster path.

Now the media path. Each participant uploads their stream once to the media server, which forwards a copy to every other participant, choosing a quality for each receiver. It does not decode or mix the video; it just routes packets, which is why one server can handle hundreds of streams. This kind of server is called a selective forwarding unit, or SFU. Let us justify that choice.

Deep dive: topology

Deep dive one: topology. In a mesh, everyone sends directly to everyone, so with ten people you upload nine copies; it only works for two or three. An MCU decodes everyone's video, mixes it into one picture and re-encodes it, which is simple for clients but burns enormous server CPU and adds delay. An SFU forwards packets without decoding and lets each receiver choose what to get. Use an SFU, and plain peer-to-peer for one-to-one calls.

             upload  server   cpu
mesh (p2p)   N-1     none     low
  ok for 2-3 people only
MCU (mix)    1       decode,  very
  one mixed  stream  re-encode high
  stream back
SFU (fwd)    1       forward  low
  each picks
  what to get

choice: SFU, p2p for 1:1

Deep dive: networks

Deep dive two: networks. Media uses UDP, because a video packet that arrives late is useless, and TCP would stall everything waiting to retransmit it. Clients sit behind home routers and corporate firewalls, so the ICE protocol tries paths in order: direct UDP to the SFU, UDP through a TURN relay, and finally TCP or TLS on port four forty-three, which almost every firewall allows. It is slower, but the call still works.

Deep dive: adaptation

Deep dive three: adaptation. Every participant's network is different, so senders encode three qualities at once, called simulcast. The SFU estimates each receiver's bandwidth from their feedback reports and picks a layer per stream: the active speaker in high quality, small tiles in low, and nothing at all for tiles that are off-screen. User B on weak hotel wifi gets only the low layer. Audio always has priority; drop video before audio. Screen share favours resolution over frame rate.

Deep dive: quality

Deep dive four: jitter and loss. Packets arrive unevenly, so receivers keep a small jitter buffer of twenty to sixty milliseconds to play out smoothly. For a few percent loss, receivers ask for a quick resend if there is time, senders add forward error correction parity packets, and the audio codec conceals small gaps. When a receiver loses video sync, it asks for a fresh keyframe. Track loss, jitter and round-trip time per participant.

Deep dive: regions

Deep dive five: regions. If user A in Mumbai and user B in Berlin both connect to one server, one of them crosses half the planet on the public internet. Instead, each connects to the nearest SFU, and the SFUs relay a single copy of each stream between regions over a private backbone. The lossy last mile stays short, and if fifty people are in Berlin, only one copy crosses the ocean. The meeting service tracks the tree of SFUs for each meeting.

Deep dive: failover

Deep dive six: failover. An SFU holds only soft state, who sends which streams to whom, so it can be replaced. The meeting service health-checks SFUs every second. When one fails, it assigns affected participants to a healthy SFU and tells them through the still-open signalling connection. Clients restart their network negotiation and republish their streams. Users see a freeze of a couple of seconds instead of being dropped.

Deep dive: webinars

Deep dive seven: webinars and recording. A hundred thousand viewers cannot each hold an SFU connection. A composer joins the meeting, mixes the panel's video once, encodes a few renditions and streams them through a CDN using HLS, with a few seconds of delay, which viewers accept. When a viewer is promoted to speak, move them onto the SFU. Recording works similarly: a hidden bot participant writes the streams to object storage, and they are transcoded later.

Deep dive: security

Security. Media is encrypted in transit with SRTP, using keys negotiated over DTLS, and the SFU can still forward it. Meetings are protected with passcodes, waiting rooms and short-lived signed join tokens. In end-to-end encrypted mode, keys exist only on clients and the SFU forwards packets it cannot read. That works because an SFU never decodes, but it means no cloud recording and no webinar transcoding in that mode.

Trade-offs

The trade-offs. SFUs are cheap to run but push decoding work and download bandwidth to clients. UDP gives low latency but you handle loss yourself. Cascading improves quality at the cost of more complex routing. Webinars over a CDN scale to huge audiences in exchange for seconds of delay. Monitor per-call loss, jitter, freeze rate, time to join and SFU egress per region. At ten times, add SFUs in more regions; there is no central bottleneck in the media path.

Interview summary

The summary. At twenty terabits a second, the media fleet is the system. Signalling runs over a WebSocket; media is RTP over UDP to an SFU, which forwards without mixing, with peer-to-peer for one-to-one calls. Senders simulcast three layers and the SFU picks one per receiver based on bandwidth. ICE falls back from UDP to TURN to port four forty-three. Everyone joins their nearest SFU, SFUs cascade across regions, and webinars go out as HLS through a CDN.