The Anatomy of a 30× Surge

In the previous post, I suggested that scalability is less about growth and more about governance. About how authority is distributed, how coordination happens, and how systems respond when growth accelerates. Organisations scale well when they intentionally design and align three core dimensions: Systems, Processes, and People.

Zoom offers one of the most dramatic stress tests of this idea. At the end of 2019, it was a successful videoconferencing company serving roughly 10 million daily meeting participants. Then COVID hit. By April 2020, Zoom was hosting more than 300 million daily meeting participants. Few software platforms have experienced such a demand spike.

The lesson is that while demand can grow exponentially, capability does not… unless it has been deliberately built to do so.

I came across this example through two complementary conversations. The first is an episode of Masters of Scale with Eric Yuan, Zoom’s founder and CEO. It tells the story from a leadership perspective: vision, culture, and mindset. Eric explains that from the very beginning, engineers were expected to assume a 10× or 20× surge in usage and ask whether the system would hold without rewriting the system's core code. That design posture helps explain why Zoom did not break during COVID.

The second is a fireside conversation with Brendan Ittelson, Zoom’s Chief Ecosystem Officer. He explains how Zoom did not break, but from an entirely different angle. He speaks about routing logic, network topology, selective media forwarding, real-time telemetry, and even procurement constraints.

These two conversations offer complementary views of scalability under pressure. One operates at the level of intent and culture; the other at the level of packets and infrastructure. Their perspectives map onto the People–Processes–Systems model introduced in the previous post. If you are interested in how organisations behave under extreme stress, both conversations are worth your time, especially when heard in tandem.

Systems: Designing for Elasticity

Zoom’s system architecture was engineered with elasticity in mind. From the beginning engineers were required to assume that traffic could spike 10× or 20× and design accordingly. When COVID drove usage 30× higher, the core code did not need rewriting. That outcome only makes sense with an understanding of the system as elastic and distributed:

• The client probes multiple data centers and selects the best-performing entry point dynamically.
• Traffic moves across a private global mesh linking Zoom’s points of presence.
• Media forwarding is selective, participants receive only the streams they need.
• Compositing happens at the endpoint, not centrally.
• Bitrate, resolution, and frame rate adapt continuously.

When networks tighten or packet loss increases, Zoom reduces video quality, prioritising audio continuity. This produces a key scalability feature: graceful degradation.

Processes: Telemetry and Feedback Loops

One of the most compelling aspects of Brendan’s account is that Zoom does not treat the Internet as stable, but as a changing environment to observe and respond to. Zoom collects telemetry across multiple dimensions: packet loss, jitter, bitrate, CPU load, Wi-Fi signal strength. That data is aggregated into what he calls an “Internet weather report.”

Weather varies by geography, by network path, by time. Telemetry informs dynamic adaptation at the client level (bitrate adjustments, routing decisions), but it also informs organisational choices: capacity planning, peering relationships, procurement priorities, enterprise support. This is where scalability becomes process, adapting service to corporate firewalls, branch offices, bandwidth constraints, and regulatory environments.

These feedback loops make the platform flexible. As conditions shift, Zoom retains the capacity to sense, decide, and adjust.

People: Trust as Infrastructure

During COVID, Eric Yuan described a workforce operating with a strong sense of responsibility, aware that schools, hospitals, and governments were suddenly depending on them.

Brendan Ittelson added that Zoom’s infrastructure had resilience and excess capacity, but not 30×. Meeting that surge required rapid cooperation from colocation providers, hardware suppliers, and network partners.

When system architecture reaches its limits and processes are fully engaged, it is trust that allows the system to stretch further. This makes it something more that just a software scaling problem, but a socio-technical governance challenge. And trust is what enables rapid negotiation of trade-offs (even lowering resolution to preserve stability), accelerated procurement decisions, and coordinated action across partners under scarcity.

Scalability as Governance

Zoom’s 30× event was a simultaneous test across different layers:

• Systems absorbed load through distributed routing, private meshing, selective forwarding, endpoint compositing, and adaptive quality.
• Processes maintained steerability through telemetry, feedback loops, and enterprise controls.
• People provided the surge capacity that no architecture can generate: mission alignment, cross-functional coordination, and partner trust.
  
And this leads to the broader point. Zoom scaled because readiness had been pre-committed technically and organisationally, long before the spike.

Scaling, often described as a growth problem, is also a governance problem: it reveals how decisions travel, how tradeoffs are negotiated, how systems adapt, and how teams coordinate under stress and volatility.