Scheduled Capacity

Autoscaling is a feedback loop, and every feedback loop has a response time: detect, decide, provision, boot, warm, register, pass health checks. For most workloads that is fast enough. For a spike triggered by a scheduled real-world event — a match start, a sale opening, a class beginning, a market open — the traffic arrives faster than the loop can close.

Scheduled capacity provisions ahead of the event because the event is on a calendar. It is unglamorous and it is the right primary control.

Why it matters

The failure mode of reactive-only scaling on a vertical ramp is the worst possible combination: requests fail during the spike, and the instances arrive afterwards and are paid for while idle. You get the cost of over-provisioning and the outcome of under-provisioning.

Implementation patterns

• Maintain an event calendar as an input to the platform, not as tribal knowledge. Sporting fixtures, sale dates, exam results, class schedules, market sessions, marketing sends.
• Provision well before the ramp — commonly thirty to sixty minutes — so instances are warm, caches are populated and connection pools are established when traffic arrives.
• Warm the caches deliberately, since a fleet of cold instances behind a cold cache will fail even at correct instance count.
• Keep reactive autoscaling as the backstop for the sustained elevated load after the spike and for the cases the calendar missed.
• Pair with admission control, because the forecast will sometimes be wrong and the excess must fail in a bounded way rather than by exhausting the fleet.
• Measure forecast error after every event and feed it back. A capacity plan that is never compared with what happened does not improve.

Industry example

Fantasy-sports platforms such as Dream11 face the extreme version: a large share of daily activity concentrates in the minutes before a match locks, and the deadline is hard — an entry rejected at lock cannot be retried later. Education platforms such as Unacademy and Physics Wallah face the same shape around scheduled classes and results announcements, and brokerages face it every trading day at the open.

In each case the load is predictable to the minute, which makes reactive scaling not merely suboptimal but unnecessary.

Failure scenarios

• Reactive scaling only, arriving after the deadline.
• Instances provisioned but caches cold, so the database absorbs the spike anyway.
• Scaling the application tier and not the dependencies — connection pools, downstream services, the identity provider, third-party quotas — so the bottleneck simply moves.
• A forecast never revised, so the same shortfall repeats.
• No shedding policy, so an underestimate becomes an unbounded failure rather than a degraded experience.

Trade-offs

Pre-provisioning costs money for capacity that is idle before the event and briefly after it. For a spike that carries a large share of daily revenue, that is trivially worth it; for a minor event it is waste.

The judgement is that the cost of pre-provisioning is known and bounded while the cost of failing a scheduled peak is neither. Where the event's value is low, the correct answer is not reactive scaling but a smaller committed capacity plus more aggressive shedding.

Interview question

"Your traffic multiplies twelve times within ninety seconds of a scheduled event. Your autoscaler is configured correctly and you still fail. Explain why, and tell me what your capacity plan looks like instead — including what you do when the forecast is 30% low."