The standard objection to pre-scaling is always the same. you are paying for compute you are not using. That objection treats idle capacity as waste. That objection is wrong.
Pre-scaling is an insurance policy with a fixed, predictable premium. The alternative is reactive scaling, which has a variable cost that shows up at the worst possible moment.
The Cost of Reactive Scaling at Peak
During the 25 million concurrent user test on June 11, peak demand hit 458,000 requests per second. Without pre-scaled capacity, reactive autoscaling would have left 157,000 requests per second hitting under-provisioned infrastructure for the 2 to 4 minutes Karpenter needs to provision new nodes.
At 25 million concurrent viewers, that window is not recoverable. Viewers who cannot connect at the start of an event rarely retry. They find an alternative. And they tell people.
The cost is not measured in compute. It is measured in lost subscribers, social media amplification of the failure, and the CDO explaining the outage to the Board the next morning.
What Pre-Scaling Actually Cost
On the day of the 25 million test, eight OVP placeholder pods held the following headroom:
| Metric | Value |
|---|---|
| OVP pod count | 8 pods (constant throughout test) |
| CPU reserved | 26.4 cores |
| Memory reserved | 104.2 GB |
| Traffic served by OVP pods | 0 RPS (pure headroom) |
| New nodes triggered | 0 |
| IGW scale-out time | Under 30 seconds |
Holding those OVP pods consumed approximately 3% of total cluster CPU reservation. That 3% was on nodes that were running regardless. The incremental cost of the headroom was effectively zero relative to infrastructure already committed.
The AI Layer Changes the Calculation
Traditional over-provisioning was a static guess. You picked a buffer and hoped it was right. The architecture described here does something different.
Quickplay's Stream Engine analyzes the event forecast, historical load signatures, and uncertainty bands to calculate exactly how much headroom each event requires. The OVP allocation is not a fixed buffer. It is a dynamic, risk-adjusted decision made per event.
For a small regional broadcast, that number is different from a 25 million user global event. The system calibrates to the actual risk profile rather than defaulting to worst-case provisioning across the board.
The Three Tiers of a Live Event Load
Every live event creates three distinct load profiles that pre-scaling must address simultaneously:
Business-as-usual load.
The background traffic where reactive autoscaling works fine. Gradual changes over hours. Standard HPA handles this without intervention.
Sustained event load.
Arriving within 60 seconds of event start, this represents a 2.75 times jump over baseline. Pre-scaled pods absorb this without triggering node provisioning.
Peak burst.
The 5x BAU spike during high-intensity moments. The Karpenter cold start window of 2 to 4 minutes makes reactive scaling physically incapable of responding in time. Pre-scaling is the only viable answer.
The cost of holding compute headroom is fixed and predictable. The cost of arriving at a live event without it is not.
The next post in this series explains what latency signals actually mean during a live event and how to tell the difference between a real failure and a bounded, expected behavior.
.webp){kind=small}
