During June and July 2026 the world was watching the World Cup. So were we, but from a different place: the operations room where we monitored the cloud infrastructure of the digital platform behind a live broadcast of the tournament — the applications, APIs, and authentication systems serving millions of simultaneous users. What gets tested with every match is everything else.
Operating a digital platform comes with a standing mandate: imperceptible latency, zero errors, and spend you can justify. What the World Cup changed was not the mandate — it was the traffic: millions of concurrent users appearing, disappearing, and returning within minutes. Sustaining the usual objectives under traffic like that is the real challenge, because they pull against each other: more capacity protects the experience but drives up cost; cutting blindly protects cost but degrades the experience.
An event like this is a stress test that no simulation fully reproduces — with no second chance if something fails. Getting through it without incidents is not luck, it is design and preparation. And the decisions behind that design apply to any platform facing demand spikes: an e-commerce site during a sales event, a financial app on payday, a content platform on premiere night.
Match-day demand is not a curve: it is a cliff
Intuition says the audience grows gradually and infrastructure can grow with it. In a live match there is no such thing as gradual. At kickoff, hundreds of thousands of people arrive within the same minute. At halftime part of the audience disconnects, and returns exactly fifteen minutes later, again all at once. And if the match goes long, the audience does not drop: it climbs. The highest-demand minutes of an entire tournament can be an extra time that was on nobody's calendar — this World Cup proved it: the final itself was decided in extra time.
Every viewer who joins generates much more than video playback: sessions to authenticate, catalogs and profiles to serve, permissions to verify. Multiplied by hundreds of thousands of people within the same minute, that work becomes a simultaneous storm on the platform's systems — hitting within seconds.
Why reactive autoscaling arrives late
Classic autoscaling works in cycles: metrics are aggregated, a threshold is crossed, new instances are requested, they boot, register, and only then receive traffic. That cycle takes minutes. The audience jump at kickoff takes seconds. By the time the new capacity is ready, the spike has passed or, worse, it has already degraded the experience of the users who arrived first.
The traffic of a scheduled event can be estimated — but from factors that live outside the platform: who is playing, how the match unfolds, how the tournament is going, audience history. None of that arrives as a usable metric on a dashboard. Part of the preparation was exactly that: turning the event's context into operable signals, so that the advance estimate and the real-time monitoring spoke the same language.
The challenge is to withstand the spike while keeping capacity, user experience, and cost in balance.
The known answer for a scheduled event is pre-scaling: provisioning capacity in advance, sized for the most demanding scenario. It works — but it forces you to decide blindly how much is enough. Our twist was to replace it with meticulous monitoring: extrapolating traffic in real time, seeing the wave form minutes in advance — how many viewers are coming in, how fast it grows, where the spike is heading — and scaling with precision: the right capacity, at the right moment. That is how you sustain the balance a live event demands: capacity for the spike, an intact user experience, and spend under control.
Scaling with precision does not work on its own; it rests on decisions made before the first match:
- Observability built for the event: audience and platform metrics in real time, in one place, so extrapolation is immediate and so are decisions.
- Aggressive caching and controlled degradation: every request that never reaches the origin is capacity you do not have to provision, and the non-essential can degrade before the broadcast is ever touched.
- Load testing against the worst possible minute, not the expected average — including the massive halftime return.
- Cloud provider quotas and limits managed in advance: those scale in days, not minutes.
Technology does not run itself
The other half of resilience is not in the architecture but in the operation: a war room active during every match, runbooks rehearsed before the tournament, real-time observability, and a team that knows the platform down to the millimeter, able to decide in seconds based on information, not panic. The incidents that never happened were prevented there, weeks earlier, in the rehearsals.
A demand spike is only an emergency for those who did not see it coming. With the right preparation and monitoring that watches it form, it becomes planned work, executed with precision. And the best sign that it went well is the same as with good refereeing: nobody had to remember you were there.