Zoom System Design Interview: Routing Live Video to Millions With an SFU
At its 2020 peak Zoom reported around 300 million daily meeting participants, up from roughly 10 million before the pandemic. It carries live audio and video over a fleet of media routers spread across data centers on multiple continents, where a single dropped video frame is fine but 200 milliseconds of extra delay ruins the conversation. The hard part is not storing data, it is moving millions of concurrent real-time streams with sub-second latency while packet loss and jitter constantly change under the network's feet.
Zoom is a real-time video conferencing system, and the whole design turns on one decision: how do you get every participant's camera and microphone to everyone else in a meeting without melting a server or a laptop. A full mesh where each client sends directly to every other client scales as N squared and dies past a handful of people. An MCU that decodes, mixes, and re-encodes one combined stream per participant is CPU-brutal and adds latency. Zoom, like most modern systems, uses a Selective Forwarding Unit: each client uploads one stream, the media router forwards the right copies down to each receiver, and no decoding or mixing happens on the server. Clients help by sending simulcast, meaning several quality layers of the same camera at once, so the router can hand a weak connection a low bitrate copy and a strong one the full resolution. Media rides UDP because a late packet is worse than a lost one, and the app leans on jitter buffers, forward error correction, and adaptive bitrate to survive real networks. Signaling, region selection to the nearest data center, large-meeting fanout, and cloud recording all sit around that media core.
Asked at: Asked at Zoom, Google, Meta, Microsoft, and most companies that run real-time communication or live streaming products. It also shows up as design Google Meet, design Discord voice, or design a live video platform, since the media core is the same.
Why this question is asked
Interviewers like this problem because it forces you off the comfortable request-response, CRUD, and database-sharding track and into real-time media, where the constraints are physics and human perception rather than storage. It cleanly separates candidates who can recite terms from those who understand why UDP beats TCP for media, why an SFU wins over an MCU and a mesh at scale, and how simulcast and adaptive bitrate keep a call alive when someone's WiFi drops. It also rewards good scoping: signaling versus media plane, one-to-one versus large meeting, and the trade-offs of recording and encryption. There is enough surface to run a full 45 minutes and enough depth to probe a senior engineer.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Users can create and join meetings with an ID, host controls, and a waiting room
- Real-time two-way audio and video between all participants in a meeting
- Screen sharing and presentation mode alongside camera streams
- Active speaker detection and dynamic gallery or speaker layout switching
- Support small calls and large webinars with hundreds to thousands of viewers
- In-meeting text chat, reactions, hand raise, and breakout rooms
- Cloud and local recording with later playback and transcription
- Mute, video off, and network quality indicators per participant
- Reconnect seamlessly after a brief network drop without ending the call
Non-functional requirements
- End-to-end mouth-to-ear latency ideally under 150 to 200 milliseconds
- Survive packet loss and jitter without freezing or dropping the call
- High availability, since a dropped meeting is immediately visible to users
- Scale to millions of concurrent participants across global regions
- Route each user to the nearest media data center for minimal round trip
- Adapt video quality automatically to each receiver's bandwidth and CPU
- Encrypt media in transit, with optional end-to-end encryption for meetings
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Peak daily participants
~300 million (2020 reported)
Zoom publicly cited roughly 300 million daily meeting participants at the April 2020 peak. This counts join events across meetings, not unique users.
Per-stream video bitrate
~0.6 to 3.8 Mbps per 720p to 1080p stream
Derived from Zoom's published bandwidth guidance. A 720p sender is roughly 1.2 to 1.8 Mbps and 1080p up to about 3.8 Mbps; audio adds roughly 60 to 80 Kbps. These are estimates from the guidance ranges.
Downlink for a gallery view
~2 to 4 Mbps for 25 tiles
Derived. With an SFU sending thumbnail quality layers, 25 low resolution tiles at roughly 100 to 150 Kbps each land near 2.5 to 4 Mbps down, far below sending 25 full streams.
Server fanout per meeting
N uplinks, up to N x (N-1) downlinks
Derived from SFU behavior. Each of N clients uploads one stream; the router forwards to the other N-1, so total forwarded copies scale with N squared even though each client still uploads only once.
Media data centers
~17 to 19 global regions (reported)
Zoom's infrastructure materials and reporting describe on the order of 17 to 19 co-located data centers plus public cloud capacity. Exact current count is not published, so treat as an estimate.
Media transport
UDP port 8801 primary, TCP/TLS fallback
Zoom sends media over UDP on port 8801 with fallback to TCP 443 or TLS when UDP is blocked. Documented in third party protocol analysis, not a derived number.
High-level architecture
A client first hits the signaling and control plane over a secure WebSocket or HTTPS connection. This plane authenticates the user, validates the meeting ID and password, applies host controls and the waiting room, and returns the address of a media zone. Region selection points the client at the nearest data center by geography and measured latency, which keeps the media round trip short. The client then opens a media connection to a Multimedia Router, Zoom's name for its distributed Selective Forwarding Unit, over UDP on port 8801, falling back to TCP or TLS if UDP is blocked by a firewall. Once connected, the client uploads a single encoded audio stream and one or more simulcast video layers. The router does not decode or mix anything. It inspects who needs what, based on each receiver's current layout, screen size, and reported bandwidth, and forwards the appropriate quality copy to each participant. Active speaker signaling flows through the same path so clients can promote the talker to the main tile. For very large meetings, additional routers are chained so one uplink can fan out across a tree of servers rather than one machine. Cloud recording is a special subscriber: a recorder joins the meeting like a participant, receives the streams, and writes composed or raw media to object storage for later transcode, transcription, and playback. Chat, reactions, and presence ride the signaling plane, kept separate from the latency-critical media plane.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Signaling and control plane
Handles meeting lifecycle, authentication, join and leave, host controls, waiting rooms, and the exchange of connection parameters. It runs over reliable transport like secure WebSockets since these messages must arrive, unlike media. It never carries audio or video, only the metadata needed to set up and steer the call.
Multimedia Router (SFU)
The heart of the system. It receives one uplink stream per client and selectively forwards copies to the other participants without decoding or re-encoding. Because it skips mixing, it uses far less CPU than an MCU and can host many more participants per machine, at the cost of pushing decode work onto clients.
Zone controller and region router
Directs each joining client to the nearest and healthiest media zone using geolocation and latency probing. It balances load across routers within a data center and handles failover if a router or zone degrades. This is what keeps the physical distance, and therefore latency, low for every participant.
Client media engine
Runs on each device to capture, encode with simulcast layers, packetize, and send media, and to receive, jitter-buffer, decode, and render. It also runs the congestion control loop that measures loss and delay and adapts bitrate. In the browser Zoom ships its own WebAssembly codecs rather than relying only on the browser's native WebRTC pipeline.
Recording and transcode service
A server-side subscriber that joins meetings to capture streams for cloud recording. It composes gallery or speaker layouts, writes to durable object storage, then runs asynchronous transcoding, thumbnailing, and speech-to-text. This is a batch pipeline decoupled from the live latency budget.
Turn and firewall traversal
Relays and fallback paths that let clients behind restrictive NATs and firewalls still reach a media router. When UDP is blocked, media is tunneled over TCP or TLS on 443. This maximizes the fraction of users who can connect at all, even if the fallback path adds latency.
Metadata and analytics store
Databases and streaming pipelines that persist meeting records, participant events, quality metrics, and billing usage. Live quality telemetry feeds dashboards and drives adaptive routing decisions, while durable records back reporting, retention, and compliance.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
meetingsmeeting_idhost_user_idscheduled_startpasscode_hashsettings_jsonstatusOne row per scheduled or instant meeting. Settings hold layout defaults, recording policy, and waiting room flag. Status tracks scheduled, live, or ended.
participantsparticipant_idmeeting_iduser_idjoin_tsleave_tsrolemedia_zone_idOne row per join event, not per user, so reconnects create new rows. Role captures host, co-host, panelist, or attendee. Media zone records which data center served them.
media_sessionssession_idparticipant_idrouter_iduplink_codecsimulcast_layersstarted_tsTracks the live media attachment of a participant to a specific router. Simulcast layers list the resolutions and bitrates that participant is publishing.
quality_eventsevent_idsession_idtsrtt_mspacket_loss_pctjitter_mssent_bitrateHigh-volume time series of per-session network health. Drives adaptive bitrate decisions live and feeds post-call quality reports. Usually stored in a time series or columnar store, not the relational core.
recordingsrecording_idmeeting_idstorage_urllayoutduration_secstatuscreated_tsPoints at objects in blob storage. Status walks from recording to processing to available. Layout notes whether it is composed gallery, active speaker, or raw per-track.
chat_messagesmessage_idmeeting_idsender_idtsbodytarget_scopeIn-meeting chat carried on the signaling plane. Target scope marks everyone, a direct message, or a breakout room. Retained per the meeting's data policy.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
SFU versus MCU versus mesh
This is the core architectural decision. A full mesh has each client send its stream directly to every other client, so a call of N people means each client uploads N-1 copies. Upload bandwidth and CPU explode past three or four participants, which is why mesh only works for tiny calls. An MCU, or Multipoint Control Unit, decodes every incoming stream on the server, mixes them into one combined video, and re-encodes a single stream per receiver. That is easy on the client but brutally expensive on the server, since decode plus encode is the most CPU-heavy work in the pipeline, and it adds latency and destroys per-user layout flexibility. An SFU, or Selective Forwarding Unit, threads the needle: each client uploads once, and the server simply forwards the right packets to the right receivers without ever decoding them. The server stays cheap and the client does its own decoding of the streams it wants. Zoom's Multimedia Router is essentially a distributed SFU. The trade-off is that receivers now download and decode multiple streams, which is why simulcast and layout-aware forwarding matter so much.
Why UDP and not TCP for media
Real-time media runs on UDP because the failure modes of TCP are exactly wrong for a live call. TCP guarantees in-order reliable delivery, which means when a packet is lost it stalls the stream and retransmits, and by the time the retransmission arrives that moment of audio or video is already stale and useless. For conversation, a late packet is worse than a lost one. UDP just keeps going, and the media engine conceals the gap with error concealment, forward error correction, or a quick re-request only when it is worth it. Zoom sends media over UDP on port 8801 and falls back to TCP or TLS on 443 only when UDP is blocked by a corporate firewall, accepting the extra latency of the fallback as the price of connecting at all. On top of UDP the app runs its own congestion control, measuring round trip time and loss to decide how much to send, rather than letting TCP's congestion control jerk the bitrate around.
Simulcast and adaptive bitrate
An SFU that forwards a single high resolution stream to everyone would drown participants on weak connections. Simulcast solves this by having each sender encode the same camera at several resolutions and bitrates at once, for example a 1080p, a 540p, and a 180p thumbnail layer, and publish all of them. The router then forwards whichever layer fits each receiver's current bandwidth, CPU, and on-screen tile size. Someone pinned to the main speaker view gets the high layer while the same speaker's tile in a 49-person gallery gets the thumbnail. This is layered forwarding done at the packet level, so no server-side transcoding is needed. Adaptive bitrate closes the loop: the client watches loss and delay and drops or raises its published layers, and receivers signal the router to switch layers as their network changes. The cost is extra upload bandwidth and encoder work on the sender, which is a deliberate trade to keep the server transcode-free and every receiver individually happy.
Jitter buffers and packet loss handling
Packets cross the internet at uneven spacing, so even if none are lost they arrive with jitter, clumped and gapped. If you played them the instant they arrived, audio would stutter. A jitter buffer holds incoming packets for a small, adaptive amount of time, reorders them, and releases them at a smooth cadence, trading a little latency for smooth playback. The buffer sizes itself dynamically: bigger when the network is jittery, smaller when it is clean, always fighting to stay small because every millisecond of buffer is added mouth-to-ear delay. For actual loss, the toolbox includes forward error correction, which sends redundant data so the receiver can reconstruct a lost packet without asking again, packet loss concealment that synthesizes a plausible fill for missing audio, and selective retransmission for video keyframes where a loss would otherwise freeze the picture until the next keyframe. Audio is prioritized over video because humans tolerate a frozen tile far better than choppy speech.
Region selection and media routing
Latency is dominated by physical distance, so the single biggest win is connecting each participant to a nearby media router. When a client joins, the control plane picks a media zone using the client's geography and measured latency to candidate data centers, then hands back a router address. Ideally all participants in one meeting land in the same data center so the SFU forwarding stays local. When participants are spread across continents, routers in different regions are linked over Zoom's backbone so a stream uploaded in one region is carried once across the backbone and fanned out locally in the other, rather than every remote participant pulling across the ocean independently. This is the same idea as a CDN for live media. Failover matters here too: if a zone degrades, the controller can migrate sessions to another router, and clients are built to reconnect quickly and resubscribe to streams without tearing down the whole meeting.
Scaling large meetings and webinars
A 10,000-person webinar breaks the simple single-router model, because one router cannot fan out one speaker's stream to ten thousand sockets. The fix is a forwarding tree: the presenter uploads once to an origin router, which forwards to a tier of edge routers, each of which fans out to a slice of the audience, so the fanout is spread across many machines rather than concentrated. Webinars also exploit an asymmetry: only a few panelists send media while the vast majority only receive, so the system does not pay N squared, it pays closer to panelists times viewers. Attendee interactions like reactions and Q and A run on the lighter signaling plane and can be aggregated. Zoom has also described a Mesh capability where on-premises devices relay streams to nearby colleagues to cut duplicate wide-area traffic inside a company, which is the same tree idea pushed to the edge of the corporate network.
Cloud recording, transport security, and encryption
Recording is architecturally a bot participant. A recorder subscribes to the meeting's streams, and depending on mode either composes a single gallery or active-speaker video or keeps raw per-track streams, then writes to durable object storage. Everything after capture, meaning transcoding to standard formats, generating thumbnails, and running speech-to-text for transcripts, is an asynchronous batch pipeline that is deliberately decoupled from the live latency budget, so a slow transcode never affects an in-progress call. On security, media in transit is encrypted, historically with AES applied to the media payloads. The important nuance for an interview is the difference between transport encryption, where the SFU can see decrypted media because it needs to route and optionally record it, and true end-to-end encryption, where keys live only on clients and the server forwards ciphertext it cannot read. Zoom added an end-to-end encrypted mode, and the trade-off is stark: with real end-to-end encryption the server cannot transcode, cannot cloud record, and certain server-assisted features are disabled, because the whole point is that the server never holds the keys.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
SFU versus MCU
SFU keeps servers cheap by never decoding or mixing, and gives every receiver a custom layout, but pushes multi-stream decode onto clients. MCU offloads clients with one mixed stream but is CPU-brutal on the server and adds latency. Zoom chose SFU-style routing to scale participant counts on the same hardware.
UDP versus TCP for media
UDP avoids head-of-line blocking and stale retransmissions, which is right for real-time media where a late packet is useless. TCP is only a fallback when firewalls block UDP, accepted for reachability despite the added delay.
Simulcast versus server-side transcoding
Simulcast makes senders encode several layers so the server can forward without transcoding, spending client upload and CPU to keep the SFU transcode-free. Server transcoding would simplify clients but reintroduce the exact CPU cost that makes MCUs expensive.
Transport encryption versus true end-to-end encryption
Transport encryption lets the server route, transcode, and cloud record, which enables most product features. End-to-end encryption gives users a stronger privacy guarantee but disables server-assisted features like cloud recording and live transcription, since the server holds no keys.
Proprietary media stack versus standard WebRTC
Zoom runs a proprietary protocol and its own codecs, even shipping WebAssembly codecs in the browser, giving it fine control over quality and bandwidth across platforms. The cost is more engineering and higher browser CPU than the native WebRTC pipeline, and less interoperability with the open standard.
Same-region colocation versus cross-region meetings
Placing all participants in one data center keeps forwarding local and latency low, which is the ideal. Globally spread meetings need backbone links between regional routers, adding hops and cost, so the system optimizes for colocation and treats cross-region fanout as a managed exception.
How Zoom actually does it
Zoom's own materials and independent analysis describe a distributed Multimedia Router that behaves as an SFU, with meetings organized into zones each fronted by a zone controller that steers clients to the nearest data center. Third party protocol reverse engineering has shown Zoom sending RTP-style media over UDP on port 8801 with TCP and TLS fallbacks, using its own H.264-based stack rather than standard WebRTC media, and even the web client historically transported media over WebSockets and later WebRTC DataChannels while decoding with custom WebAssembly codecs rather than the browser's native pipeline. On scale, Zoom publicly reported roughly 300 million daily meeting participants at the 2020 peak and expanded capacity aggressively using both its own co-located data centers and public cloud, provisioning thousands of servers from AWS during the surge. Zoom Mesh is a documented feature that lets in-network devices relay streams to cut duplicate wide-area traffic for large internal events.
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Related system design interview questions
Practice these next. They lean on the same core building blocks as Zoom.