For most platforms, autoscaling is good enough. Traffic rises gradually. CPU climbs. A threshold trips. New pods spin up. New nodes follow. The system catches up in 60-180 seconds and nobody notices the lag.

Live events break every assumption in that model.

When a major sporting event, award show, or concert begins, viewership does not ramp up. It spikes. Teams routinely observe traffic multiplying 10-50x within the first 90 seconds. At 25 million concurrent users, that translates to demand arriving faster than any reactive system can physically respond.

The Failure Sequence

Reactive autoscaling fails in a predictable order when it hits a live event spike. Here is what the timeline looks like:

• T+0s Event starts. RPS surges 10 times over in under 30 seconds.
• T+30s CPU threshold breached. Autoscaler calculates new replica count.
• T+60s New pods begin starting. Container images pull. Pods warm up.
• T+90s Pods are ready. But the nodes they need do not exist yet.
• T+120s Karpenter provisions a new EC2 node. Cold start takes 1 to 4 minutes.
• T+4min Nodes available. P99 latency is now 6 to 8 seconds. Queues have grown.
• T+6min System recovers. Most viewers have already left or complained publicly.

The gap between demand arrival and capacity availability is the window of failure. For a live event, that window is also the most valuable viewing moment. The first 60-120 seconds define the viewer experience for the entire broadcast.

Why Live Events Are Different

Three things make live events categorically different from normal traffic growth.

• Traffic arrival is scheduled and publicly known.
• The audience sets a reminder. They all arrive at the same moment. There is no gradual ramp to give your autoscaler time to react.
• Failure at the start is amplified instantly.

Social media turns a buffering screen into a trending topic within minutes. Viewers who cannot connect rarely retry. They find an alternative.

The node provisioning window is the failure.

By the time new infrastructure is ready, the audience has already formed an opinion about your platform. The window is not a delay. It is the outage.

The Architecture Answer

The solution is not faster autoscaling. Faster autoscaling still requires provisioning nodes on demand, and node cold start has a physical floor.

The answer is pre-scaling the platform to eliminate the need to provision nodes during the event at all.

Pre-scaling means having nodes already running, pods already warm, and the Istio data plane already registered before a single viewer connects. In this scenario, when the viewer spike hits, the platform does not react, it is already there.

This is not a workaround for an immature autoscaling system. It is a deliberate architectural decision. The cost of holding compute headroom is fixed and predictable. The cost of arriving at a live event without it is not.

458,000 requests per second. 4ms median latency. Zero new nodes provisioned. That is what pre-scaling looks like at 25 million concurrent users.

This is not a hypothetical solution. We've already proven it.

The next post in this series explains how we validated this architecture with 25 million concurrent users in a controlled test environment on June 11, 2026 as a pre-test to the FIFA World Cup.