41.8 How do you pre-scale for spikes?

Figure: autoscaling reacts after the spike starts; pre-scaling is ready before it.

In the chapter's code, viewers jump from 5 million to 25 million in 10 minutes. Reactive autoscaling (add servers when utilisation passes 70%, with 6 minutes to boot and warm up) leaves the API tier overloaded for 11 minutes. Pre-scaling to the expected peak plus 30% before the toss gives zero overloaded minutes. Hotstar's engineers have written that ordinary autoscaling couldn't keep up with these spikes, which is why they plan capacity ahead and rehearse with large load tests and "game days".

How to do it:

• Forecast from past matches (teams, stage of the tournament, time of day), and scale up hours before, then down after.
• Load-test at the forecast peak in advance, including the "everyone reopens the app" pattern.
• Warm caches (entitlements, home page, match metadata) before the match.
• Degrade gracefully under extreme load (Chapter 29): turn off non-essential features (recommendations, personalised rows, comments) with feature flags so video and sign-in keep working.
• Rate-limit and queue non-critical requests (Chapter 25), and make clients back off with jitter (Chapter 21).

Memory code: "Scale before the walk-out, not after it; switch off the extras when it's tight."