Skip to main contentSkip to user menuSkip to navigation

Zoom Video Infrastructure

Zoom's video conferencing infrastructure: scaling to millions of concurrent meetings with low latency.

25 min readAdvanced
Not Started
Loading...

What is Zoom video infrastructure?

Zoom video infrastructure is the distributed system that admits people to a meeting, sends their audio and video to a nearby media server, and forwards the right streams back with conversational delay. The central media component is usually a selective forwarding unit (SFU): it receives encoded streams and forwards selected quality layers without combining every participant into one new video.

In plain language: each participant publishes once, while the SFU chooses what every receiver should get. The system must adapt those choices as bandwidth, packet loss, device load, meeting size, and regional health change.

Core invariant

Protect intelligible audio and meeting continuity before video resolution, frame rate, or gallery size. A participant should be able to keep talking through congestion or recovery even when the picture becomes less detailed.

This case study designs a Zoom-like conferencing system from public protocol concepts and explicit planning assumptions. The numbers are illustrative capacity inputs, not claims about Zoom's private deployment. Review stream processing and WebRTC first if media tracks, congestion feedback, or real-time transport are new.

A meeting is a bidirectional latency contract

One-way streaming can buffer future media. A live meeting cannot: people notice late replies, overlapping speech, freezes, and repeated reconnects. The product promise is therefore not "always HD." It is "join reliably, hear people promptly, and degrade predictably when conditions worsen."

Functional requirements

  • Create a meeting, authorize participants, and issue short-lived credentials for its assigned media region.
  • Publish microphone, camera, and screen-share tracks with one or more quality layers.
  • Subscribe each participant to the active speaker, selected gallery tiles, screen share, and a bounded set of audio tracks.
  • Support mute, layout changes, device changes, participant roles, and host controls without rebuilding the meeting.
  • Move a participant or meeting to healthy media capacity after an SFU, region, or network-path failure.
  • Emit quality and routing telemetry without putting analytics acknowledgement on the media path.

Non-functional requirements

  • Keep mouth-to-ear latency low enough for natural turn-taking and measure the tail, not only the average.
  • Preserve audio under constrained bandwidth by reducing video layers before dropping the call.
  • Reserve enough SFU network and compute headroom for bursty joins, layout changes, and failover.
  • Isolate one meeting, tenant, SFU, availability zone, or region so its failure does not drain the global fleet.
  • Encrypt media in transit, authorize every subscription, minimize retained meeting metadata, and audit sensitive control actions.

Scope boundary

This lesson covers meeting admission, SFU forwarding, quality adaptation, regional placement, recovery, and operations. Codec internals, recording pipelines, transcription, chat, billing, and a complete end-to-end encryption key protocol are separate designs.

No quiz questions available
Could not load questions file
Spotted an issue or have a better explanation? This page is open source.Edit on GitHub·Suggest an improvement