Capacity planning for annual traffic spikes
Elastic capacity planning.
forecast peak from history, load-test to find per-unit capacity, use autoscaling with pre-warming and headroom, and protect with caching and graceful degradation.
What's really being asked
Whether you can meet a predictable but rare demand surge without paying for peak capacity the other fifty-one weeks.
The full answer
Forecast the peak using historical data from previous events adjusted for year-over-year growth and marketing projections. Translate that demand into infrastructure by load testing to find each instance's safe capacity, so you know how many units the forecast requires. Lean on autoscaling so capacity follows demand most of the year, keeping baseline small. For the known event, pre-scale and pre-warm capacity in advance, because reactive autoscaling reacts in minutes while a flash sale spikes in seconds, and cold starts plus scaling lag would drop requests. Add a headroom buffer above the forecast for forecasting error. Reduce the load itself with aggressive caching, a CDN for static assets, and queueing for non-critical writes. Finally, build graceful degradation and load shedding so that if demand exceeds even the buffered plan, the core purchase path stays up while non-essential features shed.
The mistakes people make
Statically provisioning for peak year-round, wasting money; trusting reactive autoscaling alone to absorb an instantaneous spike; or skipping load tests so the forecast cannot be mapped to real capacity.
What usually comes next
How much headroom buffer is reasonable? How do you pre-warm caches and connections? What do you shed first under overload? How do you validate the plan beforehand?
A concrete example
History shows the sale drives ten times normal traffic in the first minutes. You keep a modest baseline year-round, then the day before the event pre-scale to roughly the forecast plus a thirty percent buffer, pre-warm caches and database connections, and put a CDN in front of catalog pages. Autoscaling handles minor variance on top. A load-shedding rule protects checkout by degrading recommendations first if limits are hit. After the event you scale back down, so you paid for peak capacity for days, not the whole year.
Interview question
For a predictable annual flash sale spiking traffic in seconds, why is reactive autoscaling alone insufficient?
- a.Autoscaling cannot run on cloud platforms
- b.Autoscaling always over-provisions and wastes money
- c.Scaling reacts in minutes and cold starts lag, dropping requests during the initial surgeCorrect
- d.Reactive autoscaling only works for stateful services
Why? this is the answer
Reactive autoscaling adds capacity after metrics rise and new instances need warm-up time, so a second-scale spike outruns it. Pre-warming and pre-scaling ahead of the known event closes that gap; autoscaling then handles minor variance.
Just read this? Test yourself on what you have been reading.
Read the original → cloud.google.com
- #capacity-planning
- #autoscaling
- #traffic-spike
- #load-shedding
- #cost-optimization
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles