The World Cup is the largest load test ever run

The tournament starts tomorrow: forty-eight teams, three host countries, sixteen venues, and a match schedule designed so that a very large fraction of the planet is watching the same thing at the same moment, repeatedly, for a month.

From an engineering perspective this is the most demanding recurring event in consumer computing, and almost nothing about how it works gets written up.

the shape of the demand#

Synchronized, not smooth. Streaming traffic for a scheduled match is a step function. Millions of concurrent sessions establish within a two-minute window around kickoff, and the ones that fail to establish are a product failure with no recovery — the user missed the start.

Multi-peak within a session. A goal produces a spike in social traffic, in betting platforms, in messaging, in news sites, and in the streams of people switching from another match. These arrive within seconds of each other and are correlated across completely unrelated companies.

Correlated across the industry. This is the part that is genuinely unusual. Every CDN, every mobile network, every payment processor, and every messaging platform experiences the peak simultaneously. There is no borrowing capacity from a quiet neighbor, because there is no quiet neighbor.

Multi-region with different profiles. Matches in three countries across several time zones means the traffic profile shifts across the tournament in ways that capacity planning must anticipate.

what breaks, historically#

Payment processing at scale. Betting and merchandise platforms see enormous transaction spikes at specific moments. Payment processors are a shared dependency and their capacity is a hard constraint nobody downstream controls.

Mobile networks in venue areas. Sixty thousand people in one place, all trying to upload video. This is a well-understood problem with an expensive solution (temporary cell capacity) and it still degrades.

Authentication systems. Everyone logs in at once. Login is frequently the least scaled part of a streaming stack because it is not on the hot path during normal operation.

The thundering herd on recovery. Something fails, comes back, and every client reconnects simultaneously — causing a second failure. Retry jitter is the single most important line of code in a system like this and it is routinely absent.

Ad insertion. Server-side ad insertion personalizes streams per viewer while keeping segments cacheable. It is a hard constraint and it is a disproportionate source of live-stream incidents.

what the good operators do#

Pre-scale, do not autoscale. Autoscaling responds to load after it arrives. Instance startup is measured in tens of seconds; the demand arrives in one. For a known event at a known time, capacity is provisioned in advance and the autoscaler is a safety net, not the mechanism.

Load shed by feature, not by user. When capacity is short, disable the recommendations, the comments, the statistics overlay — keep the video. A degraded experience for everyone beats a perfect experience for 80% and nothing for the rest.

Multi-CDN with active steering. Not for capacity alone — for the fact that any single CDN will have a bad region on a given day. A client-side or DNS-level steering layer that measures real performance and shifts traffic is the difference between a degraded minute and an outage.

Rehearse. Group stage matches are the rehearsal for the knockout rounds. The teams that treat early matches as production load tests, with instrumentation and a retrospective after each one, are the ones that survive the final.

A war room with authority. Not a monitoring dashboard — a room with the people who can make decisions, including the decision to turn features off, without an approval chain.

the generalizable lesson#

The interesting property here is demand you cannot smooth, shed, or refuse.

Most systems get to spread load over time, queue it, or degrade gracefully by making users wait. None of those work when the product is a live event — a queue means the user misses the goal.

What is left is: provision for peak, make every layer redundant, degrade by feature rather than by user, and rehearse.

That is expensive, unglamorous, and the only thing that works. It is worth remembering the next time someone proposes autoscaling as the answer to a spike that arrives faster than a machine can boot.

Some capacity you have to already own.