Design Zoom

Problem statement

Design a cloud video-conferencing platform in the shape of Zoom: scheduled and instant meetings with multi-participant HD audio and video, screen sharing with host controls, chat, participant list, breakout rooms, and cloud recording, available globally with conversational latency. The product must work from home Wi-Fi, corporate networks with aggressive firewalls, hotel networks, and cellular links that change mid-call, and it must keep a room of 300 people synchronized to within a few hundred milliseconds.

The defining property of this problem is interactivity. A streaming platform like Twitch pushes one source to millions of viewers who tolerate seconds of latency. A video call is the opposite: every participant is simultaneously a producer and a consumer, and humans notice conversation-destroying delay above roughly 150 to 300 milliseconds one-way, the range ITU-T G.114 has used for decades of telephony engineering. That single constraint forces UDP-first transport, edge media servers close to users, adaptive encoding that reacts to bandwidth in under a second, and a control plane that can reassign failing infrastructure without ending the meeting.

What makes this different from adjacent problems

A chat system can be eventually consistent and a recording can be retried. Real-time media cannot be retried: a lost video frame is gone forever, so the design spends its complexity budget on forward error correction, jitter buffering, and congestion control instead of durable queues. A social feed can recompute later; a meeting roster must converge for everyone in the room within about a second, while the same room may contain 1,000 participants generating joins, leaves, mutes, hand-raises, and chat messages.

The public history of the category proves the scale is real. Zoom reported roughly 10 million daily meeting participants in December 2019, about 200 million by March 2020, and 300 million in April 2020, with more than three billion daily meeting minutes at that peak. Microsoft reported 300 million daily meeting participants for Teams in April 2021, and Google reported 100 million daily Meet participants in 2020. These are company-reported figures and context for our design, not requirements; every uncited number in this answer is an explicit assumption.

The four architectural planes

1. Media edge plane: the UDP-facing servers that receive, replicate, and forward encoded audio, video, and screen-share streams as close to users as possible.
2. Signaling and control plane: the WebSocket mesh that negotiates capabilities, assigns media servers, distributes rosters, and carries host commands.
3. Meeting state plane: the durable home of meetings, participants, chat, recordings, settings, billing, and moderation cases.
4. Trust and support plane: abuse detection, human review, evidence, analytics, and quality-of-experience telemetry.

A strong answer keeps these planes separate so that a control-plane outage degrades gracefully while live media keeps flowing, and so that a media-server failure can be absorbed by reassignment rather than by ending meetings.