Zoom system design interview

A Zoom system design interview looks simple until the discussion moves past "use WebRTC and an SFU." That is usually where weaker answers stall. Interviewers want to see whether you can turn a familiar product into a concrete video-conferencing system architecture with measurable constraints, failure handling, and clear trade-offs.

This matters because group video exposes several hard problems at once: low-latency real-time media, bursty traffic, unreliable networks, and room-level fan-out that can overload a design long before average traffic looks dangerous. A basic whiteboard sketch is not enough once the conversation reaches scaling and production readiness.

This newsletter covers three things:

1. How to frame requirements with capacity and latency targets.
2. Why an SFU is the default, and where it still breaks.
3. How to discuss routing, shared state, failures, and metrics like an experienced engineer.

What the system must optimize for

For interview purposes, define the problem before drawing components. A Zoom-like system supports interactive group meetings in which users create rooms, join from desktop or mobile, publish audio and video, share screens, exchange chat messages, and optionally trigger recording. Those are functional requirements, but they do not tell you which architecture to choose.

The stronger signal is converting fuzzy goals into explicit targets. In a Zoom system design interview, interactive conversation usually needs sub-300 ms end-to-end latency, with audio often requiring tighter bounds to prevent people from talking over one another. You also need high availability, regional placement close to users, and adaptation when network quality changes during a call.

Capacity assumptions matter early. A set of one-to-one calls, a ten-person team meeting, and a 200-person all-hands meeting create very different traffic patterns. In practice, candidates should state room-size bands, expected concurrent rooms, and the traffic mix, such as camera video, screen sharing, and audio-only listeners.

Note: Interviewers usually care less about exact numbers than about whether the numbers are internally consistent and drive your design.

A useful split is between the control plane and the media plane. The control plane handles auth, room membership, mute state, chat, and signaling. The media plane carries real-time audio and video packets, where latency and packet loss matter most. This signaling-vs.-media-plane split is one of the clearest ways to explain the gap between the control plane and the data plane in conferencing systems.

To make that split concrete, the architecture diagram should come early.

Separate control from media from the start.

The takeaway is simple: start with SLOs, room assumptions, and traffic classes before naming technologies. That is the foundation for clarifying the functional and nonfunctional requirements that Zoom interview questions usually test. The next question is which media topology actually fits those constraints.

Why an SFU wins for most meeting workloads

A serious answer compares an SFU, an MCU, and mesh in production terms. Mesh means that every participant sends media directly to every other participant. That works for very small calls, but uplink and downlink usage grow badly as participants increase, so client bandwidth and device CPU quickly become the limiting factors.

An #key# MCU: A multipoint control unit that receives streams, decodes and mixes or composites them, and then sends back processed outputs. #key# It reduces endpoint complexity because clients receive fewer streams. The trade-off is server-side transcoding cost, higher CPU usage, and extra latency from decode, mix, and re-encode steps.

An #key# SFU: A selective forwarding unit that routes media streams between participants without decoding the media payload. #key# It is usually the default for interactive meetings. Clients still encode their own tracks, but the server forwards selected streams to subscribers with much lower compute cost than an MCU requires.

That does not mean that an SFU is cheap. Fan-out shifts the bottleneck from media processing to outbound bandwidth, packet routing, pacing, and per-subscriber congestion control. If each publisher offers simulcast layers, the server must track subscriptions and forward the right layer to each receiver efficiently.

A concrete example helps here. In a 12-person team meeting, an SFU is usually the obvious choice because each user may watch a grid of several live cameras plus a screen share, and latency matters more than perfect visual composition. In contrast, an MCU can still make sense for a recording pipeline that needs a single mixed output or for a PSTN bridge in which the endpoint cannot handle multiple live video subscriptions. This is also where meeting-recording-vs.-live-streaming trade-offs arise naturally in a system design answer.

The trade-off summary is worth stating explicitly before going deeper.

Comparison of Mesh, SFU, and MCU Topologies

Dimension	Mesh	SFU	MCU
Latency	Lowest added latency	100-200 ms added	200-400 ms added
Client Bandwidth	Upload/Download (N-1)	Upload 1, Download up to (N-1)	Upload 1, Download 1
Server CPU	Almost none	Low to moderate	Very high
Server Bandwidth	~0	Egress scales O(N²), Ingress O(N)	Egress scales O(N)
Scalability	~4-6 participants	Dozens to thousands	20-50 participants
Quality Control	Full client-side control	Client-side layout, encryption	Server-decided layout
Best-Fit Use Case	Small/secure group calls	Large interactive meetings	Recording, low-power clients

Practical tip: Use an SFU as the default answer, then mention an MCU as a targeted addition for recording pipelines, PSTN bridges, or very weak clients.

The main takeaway is that an SFU wins because it preserves low latency while scaling better than mesh or an MCU for meetings. After that, you need to explain how signaling and media actually move through the system and how to choose among an SFU, an MCU, and a mesh topology based on workload.

How the media and signaling planes work

Once a user joins a meeting, the path should be explained step by step. The client authenticates, fetches room metadata, opens signaling over WebSocket, and negotiates media transport using WebRTC. During setup, the client gathers network candidates through STUN and TURN, then completes ICE and DTLS-SRTP to establish secure media.

A quick sequence helps keep this answer precise:

1. Auth and room lookup: Validate identity, authorization, and room policy.
2. Signaling setup: Exchange offers, answers, ICE candidates, and control events.
3. Media publish and subscribe: Send tracks to a regional SFU and receive selected remote tracks.

The signaling path carries metadata, not the media itself. It tracks membership, mute state, active-speaker hints, screen-sharing state, and subscription changes. After setup, audio and video packets bypass signaling and flow directly between the client and the SFU over SRTP, which keeps the control plane lightweight and recoverable. In practice, this is the core of real-time media routing in a Zoom-like system.

Quality adaptation depends on layered encoding. #key# Simulcast: A technique in which the sender encodes the same video at multiple resolutions or bit rates so that receivers can subscribe to different versions. #key# A related option is #key# SVC: Scalable video coding, in which a stream is encoded into dependent layers that can be selectively forwarded. #key# Both approaches let the SFU serve different receivers without server transcoding. This is the practical heart of adaptive bit rate and simulcast in video meetings.

A simple failure case makes this more concrete. If a user is on unstable Wi-Fi and the downlink drops, the SFU can switch that subscriber from a higher simulcast layer to a lower one instead of forcing a full renegotiation. If that is still not enough, the system may pause remote video tiles and preserve audio first, because degraded video is usually more acceptable than broken conversation. That is effectively how to handle packet loss and jitter in Zoom-style system discussions, even if you keep the explanation concise.

A sequence view makes this easier to discuss in an interview.

Signal first, then forward media directly.

The takeaway is that a Zoom-like design depends on a clean split: signaling manages session state, while the SFU forwards real-time media. That baseline sets up the next question: where the system actually breaks under load.

Where scaling fails under room fan-out

Many candidates say "the SFU scales horizontally" and stop there. That misses the main cost driver. In practice, load is driven less by participant count than by total active subscriptions: publishers times consumers times subscribed layers.

A 100-person room illustrates the problem. If each person publishes audio and some publish video, the system can create thousands of forwarding relationships. Even if each individual stream is modest, aggregate outbound bit rate, packet pacing, congestion feedback, and routing overhead can saturate the host.

Think in operational metrics, not just room size. Useful capacity signals include maximum outbound bit rate per server, consumers added per second, #key# jitter: Variation in packet-arrival timing that degrades smooth playback. #key# packet loss at P95 and P99, RTP router CPU, and NIC queue pressure. Autoscaling on participant count alone can hide hot rooms that dominate fan-out. This is why load estimation for video-conferencing infrastructure should focus on subscriptions and layers, not just head count.

Watch out: A room with 50 active videos can be far more expensive than several hundred mostly muted listeners. Capacity models should reflect subscription behavior, not just head count.

Mitigations are usually pragmatic rather than theoretical:

1. Room caps per node: Limit how many large rooms or subscriptions a single host carries.
2. Subscription pruning: Pause unseen video, prioritize active speakers, and lower layers for background tiles.
3. Cascaded SFUs: Distribute fan-out across nodes or regions instead of concentrating all subscribers on one box.

A common failure pattern is a company all-hands meeting with one presenter and dozens of visible participants. Average regional load may still look healthy, but one SFU host can hit outbound bandwidth or packet-pacing limits because that single room dominates subscriptions. The fix is usually not "scale everything," but to shard that room more carefully, reduce unnecessary video subscriptions, or cascade forwarding across multiple routers. That is the practical answer to "how many participants can a Zoom-like system support?" It depends more on subscription behavior than on a single room-size number.

A diagram helps make the bottleneck visible.

Fan-out, not joins, usually defines the limit.

The main point is that SFU scaling fails at outbound fan-out and routing overhead, not only at raw participant totals. Once you recognize that, the next production concern is what happens when nodes or regions fail.

How to survive node and region failures

A single healthy SFU node is not enough for a production answer. Rooms need affinity so that participants in the same meeting land on the right media router, but that mapping cannot live only in process memory. Most designs keep room-to-router metadata in a fast shared store such as Redis so that signaling services can resolve where a participant should publish or subscribe.

Sticky routing helps during normal operation. A user who reconnects after a temporary disconnect should be routed back to the same room context when possible, which reduces renegotiation and state churn. However, shared state also needs versioning because stale affinity can send users to dead processes or duplicate routers after partial failures.

Failure handling is where distributed-systems depth shows up. If an SFU process crashes, signaling should detect the loss, remap the room or affected tracks, and rebuild subscriptions from preserved metadata. If a host dies entirely, clients may need an ICE restart and track republish, but user identity and room membership should survive through the control plane. This is central to building fault tolerance in live video-call systems.

Note: #key# ICE restart: A recovery step in which endpoints gather new transport candidates and renegotiate connectivity without creating a brand-new meeting identity. #key# This is common after media-path failure.

Regional failure adds another layer. You may keep control-plane identity global while placing media regionally. That allows a user to remain in the same logical room even if media must be redirected to another region with degraded quality or a temporary reconnection delay.

Consistency trade-offs should be named explicitly. A strongly consistent room mapping simplifies correctness but can slow failover. Eventual consistency can restore service faster, but without versioned updates and idempotent rebuild logic, you can expose duplicate subscriptions, dropped tracks, or split-brain routing.

One realistic failure mode is stale room affinity after a partial outage. A signaling service may still think room R belongs to process A, while health checks have already moved new publishers to process B. If rebuild logic is sloppy, some clients reconnect to the old route, others reconnect to the new one, and you get missing tracks or duplicate subscriptions until the control plane converges.

A failure matrix keeps this grounded.

Failure Modes and Management Strategies

Failure Mode	Symptoms/Examples	Detection Signals	Recovery Mechanisms	Trade-offs
Worker Crash	Worker process stops, no heartbeats from worker	Missing heartbeats, error logs, OS-level monitoring	Restart process, job re-assignment, checkpointing	Fast detection risks false positives, more frequent checkpoints add overhead
Host Failure	Multiple services unreachable, host unresponsive	Failing health checks, loss of OS metrics	Shift workload, distributed storage, fault domain isolation	Redundancy incurs cost, live migration adds overhead
Signaling Disconnect	Commands not received, jobs hang	Discrepancies in heartbeats vs control messages	Use heartbeat channel, retry signals, fallback to defaults	Complex mechanisms increase network use, timeout risks, coupling adds architectural complexity
Redis Inconsistency	Replica lag, torn writes, stale cache entries	Replication lag metrics, keyspace events	Promote replicas, cross-shard consistency patterns	Strong consistency reduces speed, eventually consistent architecture risks stale data
TURN Exhaustion	Failed peer connections, high latency in relays	TURN server metrics, connection failure logs	Scale infrastructure, rate-limit requests, use TURN server pools	Expensive bandwidth, increased cost for availability, fallbacks affect user experience
Regional Outage	Unreachable services, error reports from affected region	Global monitoring, provider status updates, missing heartbeats	Multi-region architecture, disaster recovery plans, DNS failover	Active-active complex and costly, active-passive slower with data loss risk equivalent to replication lag

Watch out: TURN exhaustion is easy to overlook. When direct connectivity drops and relay usage spikes, a healthy SFU fleet can still look broken to users.

The takeaway is that production readiness depends on shared state, routing discipline, and controlled recovery paths. After that, the final step in an interview answer is proving the design with metrics.

What to measure and how to answer

A good design answer ends with observability, because that is how you validate the architecture instead of asserting that it works. On the client side, track RTT, estimated one-way delay, packet loss, jitter, frame rate, decode failures, join time, and reconnect rate. On the server side, monitor SFU CPU, router event-loop lag, memory, packet-queue depth, NIC saturation, and subscription churn.

Room-level quality metrics matter more than host averages. A single overloaded room can hide within a healthy regional aggregate. Many teams use percentile views at P95 and P99 for join latency, audio loss, freeze rate, and reconnect success because tails determine whether meetings feel reliable.

Practical tip: Organize metrics by user session, room, router, host, and region. That makes it much easier to answer whether the issue is local congestion, bad routing, or a broader infrastructure problem.

In an interview, the closing pattern can be compact:

1. State that the default architecture is WebRTC clients publishing to regional SFUs, with the control plane managing auth, signaling, room state, and subscriptions.
2. Mention that MCU-style processing may still appear in side pipelines for recording, PSTN interop, or special endpoints.
3. Call out the real scaling pressure: fan-out across consumers and layers, not simply participant count.
4. End with the production gap: multi-node routing, shared-state consistency, and failure recovery.

If you want more practice with this style of reasoning, developers often find useful detail in resources such as Educative's system design interview courses, Educative's WebRTC-focused content, and the MDN WebRTC guides. They are most useful once you already have a rough architecture in mind and want to pressure-test the weak spots.

The takeaway is that observability closes the loop between architecture and user experience. In a Zoom system design interview, that is often what separates a component list from a convincing explanation of trade-offs in a video-conferencing system design.

Closing

A strong Zoom system design interview answer is not about naming an SFU and moving on. It is about framing the workload, identifying fan-out as the main scaling cost, and showing how routing and shared state behave during failure. In practice, these same principles also appear outside interviews: large classrooms, internal all-hands meetings, telehealth sessions, and support calls all run into the same latency, routing, and recovery trade-offs at different scales.

If you keep the control plane and the media plane separate, define measurable SLOs early, and discuss recovery paths clearly, your answer will sound like production reasoning rather than whiteboard pattern matching. That is usually what interviewers are testing for when they ask you to design a video-conferencing system architecture under interview pressure.