Zoom Media Server Architecture
Zoom abandoned peer-to-peer video delivery early and built centralized SFU media servers with regional routing, trading server-side CPU cost for the upload bandwidth tractability that made multi-participant video calls reliable at global scale.
Zoom's core architectural decision was to build server-side Selective Forwarding Units (SFUs) rather than rely on peer-to-peer WebRTC for multi-participant calls. In a peer-to-peer model, each participant must upload their video stream to every other participant: for a 10-person meeting, each participant uploads 9 streams simultaneously, exhausting typical residential upload bandwidth within 3-4 participants. Zoom's SFU model routes every participant's stream to a central media server, which selectively forwards the appropriate streams to each participant based on active speaker detection and screen layout. Regional data center presence ensures that most participants connect to a media server within 50ms round-trip, with cross-region routing only for the inter-datacenter relay. TURN/STUN infrastructure handles NAT traversal, and Zoom's proprietary UDP protocol prioritizes low latency over reliable delivery: packet loss concealment handles gaps rather than retransmission, matching the operational characteristics of real-time audio/video.
Scale at Decision Point
Users
Zoom launched with SFU architecture pre-built; by April 2020 during COVID-19 peak, served 300 million daily meeting participants
Data Volume
Not applicable: video is streamed, not stored; meeting recordings are a separate pipeline
Request Rate
At April 2020 peak: 300 million daily participants across ~10 million meetings per day; ~3,500 new meeting starts per second at peak
17 data centers globally by 2020; co-location agreements for regional media server presence; proprietary UDP transport layer
Architecture Evolution
Initial Architecture
Zoom launched with a centralized SFU architecture from inception: the company was founded by Webex engineers who had experienced the operational limitations of peer-to-peer conferencing at scale. The initial architecture used centralized media servers in a small number of US data centers with TURN relays for NAT traversal. Early scaling issues were in connection establishment and media server capacity, not in the fundamental SFU model itself. The core issue that emerged was geographic latency: participants connecting from Asia, Europe, or South America to US-based media servers experienced 100-200ms additional latency, degrading audio quality noticeably.
- All media server capacity concentrated in US data centers: international participants experience 100-200ms additional latency
- Media server capacity planning is manual: meeting participant spikes require pre-provisioned over-capacity
- Single region failure would degrade service globally due to limited failover routing
Evolved Architecture
Global media server fleet with 17+ regional data centers and co-location agreements in additional markets. Meeting participants are routed to the nearest media server via latency-aware routing at connection time. Within a meeting, media packets traverse a dedicated inter-datacenter backbone rather than public internet for cross-region participant scenarios: two participants on opposite sides of the world both connect to their nearest regional media server, with the servers relaying between each other over Zoom's private network. A proprietary UDP transport layer handles packet loss concealment, jitter buffering, and adaptive bitrate at the media server: reducing end-to-end latency compared to TCP-based delivery. Redis is used for meeting state, participant presence, and connection signaling metadata.
- SFU media servers are compute-intensive: each video stream requires encoding, transcoding, and forwarding CPU
- Regional data center coverage requires capital investment ahead of demand: over-provisioning in low-traffic regions is necessary for reliability
- Proprietary UDP transport requires Zoom to maintain packet loss concealment and jitter buffer code that open WebRTC implementations provide for free
- End-to-end encryption at media server level requires careful key management to avoid the media server becoming a decryption oracle
Key Transitions
Trigger
Enterprise customer acquisition in Asia-Pacific and Europe was blocked by audio quality complaints traced to 120-180ms round-trip latency from regional participants to US-based media servers. Human perception of audio delay becomes disruptive above ~100ms for natural conversation; video call quality at 150ms latency is noticeably worse than in-person voice.
Before
US-centric media server fleet; international participants routed through US over public internet
After
Regional media server presence in APAC and Europe; participants routed to nearest regional cluster
Outcome
International participant latency reduced from 120-180ms to 20-50ms for APAC and European users. Enterprise sales cycles in international markets accelerated. Regional media server fleet required per-region capacity management but eliminated the single-region failure mode.
Lessons
- Audio quality perception degrades sharply above 100ms round-trip latency: international media server presence is not optional for global conferencing products
- Regional expansion must precede enterprise sales in that geography: latency problems during a sales demo close doors permanently
Trigger
Enterprise security requirements for healthcare and financial services customers mandated meeting encryption where the service provider cannot decrypt content. Zoom's SFU model inherently required media servers to decrypt, process, and re-encrypt streams: making standard E2EE incompatible with the existing SFU design.
Before
Transport encryption (TLS) for media streams; Zoom media servers have plaintext access to video/audio
After
Optional E2EE mode using client-held keys; media servers forward encrypted packets without decryption
Outcome
E2EE mode launched in 2020 with the constraint that it disables cloud recording, phone dial-in, and certain cloud-processed features (live transcription): because these features require server-side media access. The trade-off was documented explicitly for users. Enterprise security certification achieved for regulated industries.
Lessons
- E2EE and server-side media processing are mutually exclusive: you must choose which features to sacrifice before designing the encryption model
- Making E2EE optional rather than default allows graduated adoption while preserving feature set for non-regulated use cases
Trigger
Global lockdowns in March 2020 drove daily meeting participants from 10 million to 300 million in approximately 3 weeks: a 30x increase. Media server capacity, not application tier, was the binding constraint. Zoom had to add data center capacity globally faster than any planned procurement cycle.
Before
Media server fleet provisioned for ~10-15M daily participants with 2x headroom
After
Fleet expanded to 300M+ daily participant capacity through emergency cloud co-location and new data center agreements
Outcome
Service remained available through the peak despite the 30x demand increase. Some degradation in non-US regions was observed in the first two weeks before additional capacity came online. Post-surge, Zoom reported that the SFU architecture's ability to add stateless media servers horizontally was the key factor enabling the rapid expansion.
Lessons
- SFU media servers are stateless with respect to meeting history: horizontal scaling is straightforward compared to stateful architectures
- Emergency capacity expansion requires pre-negotiated agreements with co-location providers: cold procurement under load is too slow
- A 30x demand spike over 3 weeks is outside normal capacity planning models; architecture must assume eventual elastic scaling not just pre-provisioned headroom
Key Lessons
Peer-to-peer video fails at 4+ participants due to upload bandwidth exhaustion; SFU is the only scalable model for multi-participant conferencing
In a peer-to-peer WebRTC model, each participant must upload their video stream to every other participant simultaneously. For a 10-person meeting at 500 Kbps per stream, each participant must upload 4.5 Mbps: exceeding typical residential upload bandwidth. SFU centralizes this at a server with dedicated bandwidth, reducing each participant's upload to a single stream regardless of meeting size. The SFU is compute-bound, not bandwidth-bound, enabling elastic horizontal scaling.
Applicable when: You are building a multi-participant real-time media application and choosing between P2P and server-mediated delivery
Regional media server presence must be built before product-market fit is achieved in a region: latency cannot be patched post-launch
Audio quality is the primary determinant of meeting quality perception. Human hearing is sensitive to delays above 100ms for conversational cadence. A product launched into a region without local media servers will generate quality complaints that damage the brand before infrastructure can be added. The investment must precede the market entry.
Applicable when: You are building a real-time communication product and planning international expansion
Stateless media servers enable emergency horizontal scaling that stateful architectures cannot match
Each Zoom media server holds in-flight media packets for active connections but carries no durable state: a media server failure causes the affected calls to reconnect and resume on another server within seconds. This statelessness was the architectural property that made Zoom's COVID-19 capacity expansion tractable: adding servers required no data migration, no rebalancing, and no state synchronization.
Applicable when: You are designing a high-availability media processing system and choosing between stateful and stateless server models
Technologies
Patterns
Failure Modes Encountered
Related Scenarios
Sources
3 sources are pending verification and have been hidden until a followable citation is available.