Zoom

Video Conferencing

Design a video meeting service where up to 1,000 people see and hear each other with low delay, across bad networks, firewalls and continents, with recording and optional end-to-end encryption.

Overview

A video meeting service carries live audio and video between a group of people. Web apps can wait a second for a page; a conversation cannot. Once the delay one way climbs past a few hundred milliseconds, people start talking over each other, so media must flow continuously, and a late packet is worth less than a lost one.

The problem is hard for three reasons. With N people, each person wants to see N minus 1 others, so a naive design grows with the square of N. Every participant has a different network: a fiber link, hotel Wi-Fi, a phone on a train, a firewall that blocks UDP. And meetings span continents, so the servers carrying one meeting may be far apart.

The standard answer is a Selective Forwarding Unit (SFU): a media server that receives each person's stream once and forwards copies to everyone else without decoding it. RFC 7667 calls it a Selective Forwarding Middlebox. Zoom describes its own version as a network of Multimedia Routers (MMRs) that route meeting streams between participants.

Questions to ask first

How many participants in one meeting? — Most meetings are small (about 5); the limit is 1,000
Browser, desktop app, phone dial-in? — All three; the browser uses WebRTC
Recording? — Yes, cloud recording on request
Encryption? — Always in transit; end-to-end as an option that disables server-side features
Global meetings? — Yes, participants on several continents in one meeting
Delay target? — Under 300 ms mouth to ear for most participants (a target we chose)

What you will be able to do

Explain why meetings go through an SFU, and when a mesh or an MCU is better.
Walk through joining a call: SDP offer and answer, ICE candidates, STUN and TURN.
Use simulcast and congestion control to serve good and bad networks in one meeting.
Scale one meeting across regions with cascaded media servers.
Say which features need the server to see media, and what end-to-end encryption gives up.

Key concepts

SFU (selective forwarding)
Mesh vs SFU vs MCU
SDP offer and answer
ICE, STUN and TURN
Simulcast
Congestion control
Jitter buffer
Cascaded media servers
SRTP and end-to-end encryption
Recording bot

Functional requirements

Create a meeting and join it by ID and passcode, with an optional waiting room
Send and receive audio and video; share a screen
Show an active speaker view and a gallery view
Support meetings of 2 to 1,000 participants
Record a meeting to the cloud and play it back later
Offer end-to-end encryption as a meeting option

Non-functional requirements

Mouth-to-ear delay under 300 ms for most participants (a target we chose)
Keep audio working when video cannot: audio first under loss
Work behind NATs and firewalls, falling back to TCP or TLS on port 443
A media server failure costs a few seconds of media, not the meeting
Media is always encrypted in transit

Interview questions

Why use an SFU instead of peer-to-peer connections?
Walk me through what happens when someone clicks Join.
What are STUN and TURN, and when do you need TURN?
How does one meeting serve people on very different networks?
How do you support a 1,000-person meeting spread across continents?
Why UDP, and how do you handle packet loss?
How does recording work, and why is it disabled with end-to-end encryption?
What happens if a media server dies in the middle of a meeting?