How Zoom Actually Works

In early 2020, Zoom went from roughly 20 million daily meeting participants to over 300 million in a matter of weeks. Most platforms would have buckled under a 15x traffic spike arriving with essentially no warning. Zoom mostly didn't, and the reason traces back to architectural decisions made years earlier, when the company was still a small, relatively unknown challenger competing against much bigger, well-established video conferencing vendors.

This article looks at how Zoom is actually built the routing model that lets a single meeting scale to thousands of participants without a server ever having to decode and re-encode everyone's video, the clever single-stream trick that adapts to every participant's bandwidth simultaneously, and the globally distributed zone system that keeps a meeting fast no matter where in the world its participants happen to be. Zoom, like a couple of other platforms in this series, doesn't run much of a public engineering blog, so this draws on detailed public system-design breakdowns, an official infrastructure document Zoom itself published, and general engineering practice in this space.

The Old Way: One Server Doing Everyone's Heavy Lifting

To appreciate what Zoom actually did differently, it helps to understand the traditional approach it moved away from. Older video conferencing systems typically relied on something called a Multipoint Control Unit, or MCU. A breakdown on CometChat's engineering blog explains how an MCU works: it receives every single participant's video and audio stream, decodes all of them, mixes them together into one combined stream, and then sends that single mixed stream back out to everyone.

A single translator sitting in the middle of a room full of people speaking different languages, individually listening to every single person, mentally combining everything said into one summary, and then repeating that summary back out to the whole room that translator becomes the bottleneck the entire conversation depends on, and asking them to handle a much bigger room means they simply have to work much harder, with no real limit to how much harder that can scale. An MCU carries exactly that same structural weakness: every meeting participant added means more decoding, more mixing, and more re-encoding work piling onto the same central server, and that computational cost grows directly with meeting size.

Zoom's Answer: Route the Streams, Don't Mix Them

A piece on High Scalability explains the alternative Zoom built instead, called Multimedia Routing: rather than decoding, mixing, and re-encoding every stream centrally, Zoom's servers simply route each participant's already-encoded video directly to the other participants who need to see it. The same piece is direct about the payoff: cutting out that central transcoding step removed a major source of latency and dramatically increased how far the system could scale.

A postal sorting facility that looks at the address on a package and forwards it directly to the right destination, without ever opening the box, repackaging its contents, and resealing it before sending it onward the sorting facility (Zoom's Multimedia Router) does real, meaningful work routing things correctly, but it never touches the actual contents of what's being delivered, which is exactly what keeps it fast even as far more packages start flowing through at once.

Traditional MCU approach:
  Every participant's stream → decode → mix into one combined stream
    → re-encode → send the same mixed stream to everyone
  Cost grows steeply as more participants join
 
Zoom's Multimedia Routing approach:
  Every participant's already-encoded stream → routed directly
    → to exactly the participants who need to see it
  No central decode/mix/re-encode step at all

One Stream, Every Resolution: Scalable Video Coding

Here's where the engineering gets genuinely clever, and it solves a real problem: different participants in the same meeting have wildly different bandwidth and screen sizes. Someone on a large monitor over fiber internet wants sharp, high-resolution video. Someone on a phone over a shaky mobile connection needs something much smaller and lighter, or their whole call falls apart.

The naive fix would be having each sender encode and transmit several completely separate video streams, one per resolution expensive, wasteful, and heavy on both the sender's upload bandwidth and the server's processing load. High Scalability's breakdown explains Zoom's actual approach: Scalable Video Coding, or SVC, encodes a single stream that contains multiple layers, all bundled together in roughly 1.2 megabits per second, letting the system scale down to whatever resolution and bitrate a specific recipient's network conditions actually call for. The same piece notes this used to require dedicated hardware chips to pull off, but thanks to steadily improving processors, it can now be done entirely in software.

Baking a single, large layered cake where each layer can be served on its own as a smaller, complete dessert, rather than baking five entirely separate cakes of different sizes from scratch one baking effort, produced once, still gives every guest a portion sized appropriately for their own appetite. A participant's device essentially requests a certain layer of the stream, and the router hands over the version already sized to fit exactly what that device asked for, without the original sender needing to have produced several completely separate video feeds in the first place.

Sender encodes ONE layered SVC stream (~1.2 Mbps)
  → Contains multiple embedded resolution/bitrate layers
 
Participant on fiber, big monitor    → subscribes to a high layer
Participant on shaky mobile data     → subscribes to a lower layer
 
Same original stream, different layers served, no separate re-encoding needed

Meeting Zones: Bringing the Server Close to the People in the Call

Distance is one of video calling's oldest enemies the further data physically has to travel, the more latency creeps into a conversation, and a half-second of lag is the difference between a smooth conversation and everyone awkwardly talking over each other. A write-up on Talent500 describes how Zoom's data centers are organized into Meeting Zones, each one built around two core components: a Multimedia Router, which efficiently manages the various video streams flowing through that zone, and a Zone Controller, which manages and orchestrates all the activity happening inside that specific zone.

The same breakdown on GeeksforGeeks explains the practical routing logic this enables: meetings get distributed across Zoom's global data center network, letting users join a call through whichever data center happens to be physically closest to them, which keeps latency down and reliability high even for meetings with participants scattered across several continents.

Choosing a restaurant near where the majority of a dinner group actually lives, rather than making everyone travel to one fixed, distant location regardless of where they're each coming from a meeting gets assigned to whichever nearby "restaurant" (data center) makes the most sense for the people actually attending, rather than every single meeting in the world being forced through one single, potentially very distant hub.

A Network of Escape Hatches: How Zoom Refuses to Just Fail

Corporate networks are notoriously unpredictable some block certain ports outright, some sit behind strict firewalls, some route everything through a proxy that mangles unusual traffic patterns. A resilient video platform can't just assume a clean, direct connection is always available.

A Zoom-published infrastructure document, Zoom Global Infrastructure, describes what it calls the Intelligent Transport Layer, sitting at the very base of the client's networking stack deciding on the fly whether UDP, TCP, TLS, or HTTPS will give a given user the best possible connectivity, based on their specific proxy settings and whatever firewall restrictions they happen to be navigating. The same document adds a further layer of resilience underneath that: failover between different internet service providers happens automatically, and the document states plainly that even if four separate ISPs were all down simultaneously, the Zoom service would still keep working.

A write-up on Medium by Santosh P. describes one more fallback layer sitting underneath all of this: HTTP tunnels, present in every Meeting Zone and across Zoom's public cloud infrastructure, exist specifically as a last-resort connection point for participants whose network completely blocks every other connection strategy Zoom tries first.

A building with a main entrance, several side doors, a freight elevator, and, if truly nothing else works, a fire escape the specific building never really cares which door you actually used to get inside, as long as you made it in. Zoom's layered fallback strategy works the same way: try the fastest, most efficient path first (usually UDP), and if that's blocked, quietly keep trying alternative doors until one of them actually lets the connection through.

Client attempts connection
  → Try UDP (fastest, best for real-time media)
      Blocked by firewall/proxy?
  → Fall back to TCP
      Still blocked?
  → Fall back to TLS
      Still blocked?
  → Fall back to HTTPS
      Still nothing working at all?
  → Fall back further to an HTTP tunnel as a last resort

Two People, No Server Needed at All

Here's a nice bit of restraint worth calling out: not every call needs the full weight of this infrastructure. A breakdown on La Vivien Post notes that when a meeting has only two participants, Zoom uses a direct peer-to-peer connection instead of routing the call through its server infrastructure at all only stepping in with the full Multimedia Router setup once a call actually needs to coordinate three or more participants simultaneously.

Two neighbors who can just talk to each other over the fence directly, with no need to route their conversation through the neighborhood's community bulletin board that bulletin board (the server infrastructure) only actually earns its keep once there's a genuinely larger group that needs coordinating. Reserving the heavier infrastructure specifically for calls that actually need it is a small detail, but it reflects the same underlying instinct running through the rest of Zoom's design: don't spend more computational effort than a given situation actually calls for.

Putting It Together

None of the individual pieces here are exotic inventions on their own. Media routing versus media mixing is a well-understood distinction in video engineering. Scalable Video Coding is a documented, published video compression technique. Geographically distributed data centers and layered network fallbacks are common patterns across large-scale infrastructure generally. What made Zoom's architecture genuinely well-suited to a sudden, enormous surge in demand wasn't any single piece of exotic technology it was consistently choosing the lighter-weight option at every layer: route instead of transcode, encode once with embedded scalability instead of re-encoding per recipient, connect directly when only two people are involved instead of always defaulting to the heavier infrastructure, and keep several fallback paths ready rather than assuming any single connection strategy would always just work.

What This Means Going Forward

As video conferencing keeps absorbing more participants per call, higher resolutions, and increasingly demanding features like live transcription and AI-generated meeting summaries layered directly onto the real-time stream, the same fundamental tension keeps resurfacing: how do you keep adding capability without adding proportional cost and latency to something that has to feel instantaneous to actually work. The lesson underneath Zoom's story isn't really about SVC, or Meeting Zones, or the Intelligent Transport Layer specifically. It's the same one running through this entire series: an architecture built to survive a crisis it never even anticipated by name was really just an architecture built, from the very beginning, around lean, adaptable defaults rather than assuming every problem needed to be solved by throwing more raw compute at it.