Design Zoom

"Design Zoom" separates candidates who have only practised request/response systems from those who have thought about real-time media. Little of what you learned designing a chat app or designing WhatsApp carries over to the video path: no message queue, no durable inbox, no retry-until-acked. Packets that arrive late are simply discarded.

What follows is a reasonable design an interviewer would expect, not a description of Zoom's actual internals. The building blocks — SFUs, ICE with STUN/TURN, simulcast, jitter buffers — are publicly documented approaches used across the industry, and that is the level to reason at.

  SIGNALLING PLANE (TCP/HTTPS, reliable)
   +---------+        +--------------------+       +-------------+
   | Client  | <====> |  Signalling / API  | ----> |  Meeting DB |
   |  A / B  |        |  join, SDP, ICE    |       | rooms, auth |
   +---------+        +--------------------+       +-------------+
        |                        |
        |                        v
        |               +-----------------+
        |               | STUN / TURN     |
        |               | NAT traverse    |
        |               +-----------------+
        v
  MEDIA PLANE (UDP, best-effort, low latency)
   +---------+   RTP    +------------------+   RTP   +---------+
   | Client A| =======> |   Edge SFU       | ======> | Client B|
   +---------+          | forward, no      |         +---------+
   +---------+ =======> | transcode; picks | ======> +---------+
   | Client C|          | layer per viewer |         | Client D|
   +---------+          +--------+---------+         +---------+
                                 |
                                 v
                        +------------------+
                        | Recording / MCU  |
                        | mix -> blob store|
                        +------------------+

1. Clarify the requirements

Functional requirements

• 1:1 calls and group calls up to a few hundred participants
• Audio, video, and screen sharing, with mute and camera-off controls
• Join by meeting ID or link, with a host, waiting room, and participant list
• Cloud recording, produced as a single playable file afterwards
• In-meeting chat and simple reactions

Non-functional requirements

• End-to-end latency under roughly 150 ms so conversation feels natural; jitter matters as much as the average
• Graceful degradation on bad networks rather than disconnection
• Global reach — participants in different regions in the same meeting
• High availability: a failing media node must not end the meeting

Back-of-the-envelope scale. A 720p stream runs roughly 1.5 Mbps, audio around 40 kbps. In a 10-person call each participant sends one stream up and receives nine down — ~1.5 Mbps up, ~13 Mbps down — which is already why clients cannot receive full quality from everyone. Once you stop transcoding, bandwidth rather than CPU is the dominant constraint.

2. Why media does not go through the normal API path

Every other system in this series funnels traffic through a load balancer, an API tier, and a datastore. Media cannot use that path for three reasons:

• Latency budget. Speech is uncomfortable past roughly 200 ms one way; extra hops, TLS termination, and application queuing spend that budget before the packet leaves your data centre.
• Nothing is stored. A media packet is consumed and discarded within milliseconds, so durability — the reason most backends exist — is irrelevant.
• Volume. One 10-person meeting produces more bytes per second than thousands of API calls.

Hence two planes. The signalling plane is ordinary infrastructure — HTTPS and WebSocket over TCP, backed by a database — handling auth, meeting records, join and leave, participant lists, chat, and the negotiation of media parameters. The media plane is UDP flowing to purpose-built media servers that hold no durable state. Interviewers reward candidates who draw this split in the first two minutes.

3. Transport: why UDP wins

TCP guarantees ordered, complete delivery, and both guarantees are actively harmful here. A lost packet blocks everything queued behind it while it is retransmitted — head-of-line blocking — so one drop becomes a visible freeze, and retries pile up exactly when the network is already congested.

Real-time media therefore uses RTP over UDP (secured as SRTP, with DTLS handshakes) — the WebRTC stack. Loss is handled by the application, which has better options than blind retransmission: conceal a missing audio frame, drop a video frame, or request a fresh keyframe. Selective retransmission exists for small recent gaps, but only where the packet can still arrive in time to matter. TCP remains the fallback for networks that block UDP, and the visible quality drop is itself the argument.

4. Topologies: mesh vs MCU vs SFU

This is the core of the question, and the interviewer wants all three compared before you commit.

Mesh (peer-to-peer). Every participant sends directly to every other, so with N people each client uploads N-1 streams and connections grow as N². No server media cost and the lowest possible latency — excellent for 1:1, unusable past three or four participants because home upload links saturate.

MCU (Multipoint Control Unit). The server decodes every incoming stream, composites them into one video, re-encodes, and sends each participant a single stream. Clients get the easiest job — one stream up, one down — which is why the approach persists for low-power endpoints and telephony bridges. The cost is severe: decoding and re-encoding everything burns server CPU, the extra encode adds latency, and everyone receives the same fixed layout.

SFU (Selective Forwarding Unit). The server receives one stream per participant and forwards packets without decoding them. Each client uploads once regardless of meeting size and receives a selected subset of the others. Server cost is routing rather than transcoding, and because streams stay separate, each receiver can be sent different qualities and arrange the layout itself.

The answer: SFU for group calls, optionally peer-to-peer for 1:1 when a direct path exists, with MCU-style mixing reserved for recording and telephony gateways. That combination is why SFUs are the industry default.

5. Signalling and NAT traversal

Before media flows, the two ends must agree on codecs, encryption keys, and a network path. The signalling plane carries session descriptions (SDP offers and answers) and candidate addresses; it never touches the media itself.

Path discovery is the hard part. Almost every client sits behind NAT and does not know the public address and port through which it can be reached. A STUN server answers exactly that question, reporting the public mapping it sees. Candidates from both ends are then tried in parallel (the ICE process) and the best working pair wins. When no direct path succeeds — symmetric NAT, strict corporate firewalls — a TURN server relays media instead. Relaying always works but consumes real bandwidth, so it stays a fallback for the minority of sessions that need it. With an SFU, media already terminates on a server, so this mostly concerns reaching the SFU rather than peer discovery.

6. Bandwidth adaptation, simulcast, and loss

An SFU forwards packets and does not transcode, which raises an obvious problem: how does a viewer on a weak connection get a lower-quality version? The answer is that the sender produces several qualities up front.

• Simulcast. The client encodes and uploads the same video two or three times at different resolutions and bitrates; the SFU forwards whichever version each receiver can handle, so one weak participant no longer degrades the whole call.
• Scalable video coding. A layered encoding the server can strip higher layers off — less upload than simulcast, more codec complexity.
• Congestion control. Bandwidth is estimated continuously from arrival timing and receiver feedback, and the sender adjusts bitrate and frame rate rather than waiting for loss.
• Degradation order. Protect audio first: drop resolution, then frame rate, then video entirely.

On the receiving side a jitter buffer holds arriving packets briefly to smooth uneven network timing, reordering them and paying a few tens of milliseconds for steady playback. It sizes itself adaptively — larger on a jittery link, smaller on a clean one. Losses that get through are patched by concealment for audio, or by holding the previous frame and requesting a keyframe for video.

7. Recording and global placement

Recording is the one place mixing earns its cost. A recording node joins as an invisible participant, receives all streams from the SFU, and composites them into a single track — off the live path, so it never adds latency for participants. The output lands in blob storage, is transcoded into a few playback renditions, and is served through a CDN like any video-on-demand asset.

Global placement follows from the latency budget. Media servers sit in edge locations worldwide and participants connect to the nearest healthy one; for a meeting spanning regions, the SFUs interconnect over a private backbone so cross-region traffic takes a controlled path. Assignment is a signalling-plane decision made at join time, weighing geography, node load, and health. Because media servers hold no durable state, failure is recoverable: participants reconnect to another node and the meeting resumes in seconds.

Key trade-offs the interviewer probes

• Latency vs reliability. UDP and best-effort delivery, always. A design reaching for guaranteed delivery on the media path has misread the problem.
• SFU vs MCU. SFU for scale and per-receiver flexibility; MCU only for weak endpoints or recording.
• Simulcast cost. Several qualities raise client upload and CPU, but stop one weak viewer dragging the meeting down.
• Encryption depth. Hop-by-hop encryption to the SFU is standard, since the server reads packet headers to route. True end-to-end encryption means forwarding payloads the server cannot inspect, which constrains features like cloud recording — a trade worth naming out loud.

FAQ

Why does video conferencing use UDP instead of TCP?

TCP retransmits every lost packet and delivers strictly in order, so one dropped packet stalls everything behind it and the delay compounds. For live video a packet that arrives late is worthless, because the moment it described has already passed. UDP lets the application drop what is late and keep playing, and codecs conceal the loss, so a conference trades perfect data for low, steady latency.

What is the difference between mesh, MCU, and SFU topologies?

In a mesh every participant sends their stream directly to every other participant, which is simple but grows as the square of the group and saturates upload bandwidth past three or four people. An MCU decodes all incoming streams on the server, mixes them into one composite, and sends a single stream back, which is cheap for clients but very expensive in server CPU. An SFU receives each stream once and selectively forwards the packets without decoding, which is the middle ground and the reason it dominates group calling.

Why do most group calls use an SFU?

An SFU keeps client upload at a single stream regardless of how many people are in the call, while avoiding the transcoding cost of an MCU because it forwards packets rather than decoding and re-encoding them. It also preserves per-participant streams, so each receiver can be sent a different quality and the client can lay out the video however it wants. That combination of low server cost and per-receiver flexibility is why it is the standard choice.

What do STUN and TURN do in a video call?

Most devices sit behind NAT and do not know the public address and port through which the outside world can reach them. A STUN server tells a client what that public mapping is so peers can attempt a direct connection. When the network is restrictive enough that no direct path works, a TURN server relays the media instead, which always succeeds but costs bandwidth, so it is used as a fallback for a small share of sessions.

How does a call adapt when someone's connection degrades?

Senders publish the same video at several qualities at once using simulcast or a layered codec, and the server forwards whichever layer each receiver can currently handle. Congestion control estimates available bandwidth from arrival timing and loss feedback, and the client drops to a lower layer, reduces frame rate, or falls back to audio only. Audio is protected first because a call survives frozen video but not broken sound.