How Would You Design Zoom?
Learn how to design a Zoom-like video calling system: SFU media servers, signaling, STUN/TURN, and simulcast.
Expected Interview Answer
Design Zoom around a Selective Forwarding Unit (SFU) media server model: each participant sends one encoded video/audio stream up to a nearby SFU, and the SFU forwards (rather than re-encodes) copies of the relevant streams down to every other participant, with a signaling service handling call setup and a TURN/STUN layer handling NAT traversal.
When a meeting starts, clients use a signaling service (typically WebSocket-based) to exchange session descriptions and negotiate connectivity via ICE, using STUN to discover public addresses and TURN to relay traffic when a direct peer path is blocked by NAT or firewalls. Once connected, each participant uploads a single encoded stream to a geographically nearby SFU media server rather than to every other participant directly, which avoids the N-squared bandwidth blowup of a full mesh. The SFU forwards each participant’s stream to every other participant’s downlink, optionally applying simulcast (multiple quality layers per stream) so it can send lower-resolution copies to participants on constrained connections without re-encoding. Recording, transcription, and screen-share are handled as additional media tracks or side services that consume the same SFU streams. For very large webinars, the architecture shifts toward a CDN-style fanout (one-to-many broadcast) instead of SFU forwarding, since most viewers do not send video back.
- The SFU model avoids the bandwidth explosion of full mesh peer-to-peer for calls beyond a handful of participants
- Forwarding without re-encoding keeps SFU CPU cost low and latency minimal compared to a transcoding MCU
- Simulcast lets the SFU serve different quality levels to different participants from one upload
- Separating signaling from media transport lets each scale and fail independently
AI Mentor Explanation
Designing Zoom is like a stadium’s broadcast relay tower that receives one feed from the pitch-side camera and redistributes copies to every regional broadcaster, instead of the camera operator sending a separate feed to each broadcaster directly. The tower (SFU) just forwards the signal without re-shooting the footage, which keeps the relay fast and cheap even as more broadcasters tune in. Some broadcasters get a lower-bandwidth copy for weaker links (simulcast) while others get full quality. That one-upload, many-forward relay model is exactly how Zoom’s media servers handle video calls.
Step-by-Step Explanation
Step 1
Signal and negotiate connectivity
Clients exchange session descriptions over a signaling service and use STUN/TURN via ICE to establish a media path.
Step 2
Upload once to the SFU
Each participant sends a single encoded stream to a nearby SFU media server instead of to every peer.
Step 3
Forward to other participants
The SFU forwards (without re-encoding) each stream to every other participant, optionally using simulcast for quality tiers.
Step 4
Handle scale-out cases
Large webinars shift to CDN-style one-to-many fanout since most viewers only receive, not send, video.
What Interviewer Expects
- Explains why full mesh peer-to-peer breaks down beyond a handful of participants (N-squared bandwidth)
- Describes the SFU model as forward-not-transcode and contrasts it with an MCU
- Mentions STUN/TURN/ICE for NAT traversal and a separate signaling channel
- Discusses simulcast or scalable video coding for heterogeneous participant bandwidth
Common Mistakes
- Proposing full mesh peer-to-peer for large group calls without noting its bandwidth limits
- Confusing signaling (call setup) with the actual media transport path
- Ignoring NAT traversal (STUN/TURN) entirely
- Assuming the SFU must decode and re-encode every stream like an MCU, adding needless CPU cost
Best Answer (HR Friendly)
“I would design Zoom so each person’s camera uploads just once to a nearby media server, which then forwards that same stream out to everyone else in the call instead of re-processing it. This keeps the system efficient as more people join, and for very large webinars I’d switch to a broadcast-style fanout since most viewers are only watching, not speaking.”
Code Example
async function onIncomingStream(meetingId, participantId, mediaTrack) {
const room = await rooms.get(meetingId)
room.tracks.set(participantId, mediaTrack)
for (const other of room.participants) {
if (other.id === participantId) continue
const quality = other.bandwidthTier // low | medium | high
const layer = mediaTrack.simulcastLayers[quality] || mediaTrack.simulcastLayers.medium
other.connection.forward(participantId, layer) // no re-encode, just relay
}
}Follow-up Questions
- How does an SFU differ from an MCU (multipoint control unit) in terms of CPU cost and latency?
- How would you handle a participant switching networks mid-call without dropping the meeting?
- How would you design recording so it does not add load to the live media path?
- How would large webinars with thousands of viewers change this architecture?
MCQ Practice
1. Why does Zoom-style video calling use an SFU instead of full mesh peer-to-peer for group calls?
In full mesh every participant sends to every other participant, so bandwidth and CPU cost grow with the square of participant count.
2. What does an SFU do with an incoming media stream?
An SFU relays streams as-is, which is far cheaper than an MCU that decodes and re-encodes every stream into a composite.
3. What problem does TURN solve in a video call architecture?
TURN servers relay traffic when STUN-based direct connectivity is not possible due to restrictive NATs or firewalls.
Flash Cards
What does an SFU do? — Forwards each participant's stream to other participants without decoding/re-encoding it.
Why not use full mesh peer-to-peer for group calls? — Bandwidth and CPU cost scale quadratically with participant count.
What is simulcast? — Sending multiple quality layers of the same stream so the SFU can serve different bandwidths without transcoding.
What does TURN do? — Relays media traffic when a direct connection is blocked by NAT or firewalls.