Zoom's daily meeting participants went from roughly 10 million in December 2019 to roughly 300 million by April 2020. No forecast produced that number. Which planning posture best survives a demand shift of that size?

The deciding property

A 30× shift in four months is outside the range any forecast produces, so the posture cannot depend on the forecast being right. The question is not "how do we predict it" but "what does the system do when we are wrong by an order of magnitude in either direction".

That reframes the problem from capacity to elasticity plus degradation: how fast can capacity arrive, and what does the product do in the hours before it does. Zoom's own answer publicly included bursting onto multiple public clouds alongside its own data centres — short scaling paths mattered more than an accurate number.

Why designing for degradation wins

Two mechanisms:

• The scaling path is the binding constraint, not the plan. Capacity that takes six weeks to install cannot respond to a shift that happens in three. Capacity that takes an hour can. So the useful investment is removing steps between "we need more" and "it is serving", which is architecture work, not forecasting work.
• Degradation converts an outage into a worse product. A video service that can drop to lower resolution, fewer simultaneous streams, or audio-only has a graceful response to 10× demand. One that cannot has a binary one. Decide the axis in advance, because under load you will not get to choose it.

Why the other options fail

• "Forecast further out and provision to the upper bound." The upper bound of a forecast is drawn from the same distribution that missed. Worse, provisioning to it burns money continuously for an event that in most quarters does not come, which is how the practice gets cancelled just before it is needed.
• "Commit to reserved capacity at the highest plausible level." This is the same error with a contract attached. Reservations buy a discount on capacity you were going to use anyway; they are a cost instrument, not an elasticity instrument, and they make the wrong guess more expensive to unwind.
• "Build a second architecture and switch." A system you do not run is a system that does not work. The switch happens under the worst conditions you will ever have, on a path nobody has exercised. Two architectures means the untested one is the one you need.

When this is over-engineering

For a workload whose demand is set by a contract — an internal tool with 4,000 employees, a batch job whose input volume is known a quarter ahead — the forecast really is reliable, and elasticity machinery is cost with no matching risk. The posture changes when demand is set by the outside world rather than by your own customer list.