Pre-Scaling

Autoscaling is a feedback loop: observe load, decide, provision, initialise, join the pool. Each step takes time, and the total is typically minutes. For traffic that grows over hours, that is entirely adequate and autoscaling is the correct mechanism.

For a scheduled event it is not. When a match starts, a sale opens, a game event begins or a ticket on-sale goes live, the population arrives within a few minutes — often within one. By the time the loop has responded, the event has already failed, and the newly-provisioned capacity joins a system that is already in a degraded state and possibly in a retry storm.

Pre-scaling replaces the loop with a decision: capacity is provisioned, warmed and verified before the event begins.

Why it matters

The failure mode is not gradual. A system that is 3× under-provisioned at the moment of arrival does not serve a third of the traffic slowly — it saturates, queues, times out, triggers retries, and serves close to nothing while the autoscaler is still deciding. Recovery from that state is far harder than avoiding it, because the retry load persists after capacity arrives.

The economic argument is straightforward and is often not made explicitly: for a scheduled event, the cost of over-provisioning is a known, bounded, one-day figure, and it is compared against a public failure of a heavily-marketed event. Framed that way the decision is rarely difficult; framed as "why is our cloud bill high this month" it is.

Implementation patterns

• Provision hours in advance, not minutes, so that provisioning failures are discovered while there is time to react.
• Warm everything on the path: connection pools, JIT-compiled code paths, caches, DNS resolution, TLS session caches, and any lazily-initialised resource. A newly-started instance is not equivalent to a running one, and cold instances added at peak can degrade the pool they join.
• Verify capacity availability with the provider in advance. A pre-scaling plan that assumes a particular instance type will be available in a particular region at 7pm is a plan with an unverified dependency.
• Keep autoscaling enabled above the pre-scaled floor, as a safety net rather than as the mechanism.
• Pre-allocate stateful resources — game instances, session slots, database connections — so that joining is an assignment rather than a creation.
• Pre-warm caches with the data the event will need, so the first minute is not a cache-miss storm.
• Scale down deliberately afterwards, on a schedule, since forgotten pre-scaled capacity is a recurring and embarrassing cost item.
• Load test at the pre-scaled size to confirm the configuration actually serves what it is supposed to.

Industry example

Every organisation running scheduled mega-events converges on this practice: streaming platforms preparing for record live-cricket concurrency, game publishers preparing for in-world events with tens of millions of simultaneous players, and retailers preparing for annual sale events.

The published accounts share a consistent shape — capacity provisioned hours ahead at a multiple of forecast, caches warmed, a change freeze in effect, and autoscaling relegated to a backstop. The recurring lesson is also consistent: the events that failed usually failed on a dependency nobody pre-scaled — a third-party payment provider, an identity service, a rate-limited external API — rather than on the capacity that received all the attention.

Failure scenarios

• Relying on autoscaling for a scheduled spike, which is the default and the most common cause of failure.
• Pre-scaling the application and not the dependencies — database connections, caches, third-party quotas, message brokers, load balancer capacity.
• Cold instances that are provisioned but not warmed, adding latency to the pool at the worst moment.
• Provisioning too close to the event, leaving no time to react to a capacity shortfall.
• Assuming provider capacity, which may not be available at the required scale in the required region.
• Forgetting to scale down, producing a cost surprise.
• Pre-scaling without load testing at that size, so a configuration limit — a connection cap, a thread pool bound — throttles the system well below the provisioned capacity.

Trade-offs

Pre-scaling costs money for capacity that is idle until the event, and the multiple applied above forecast directly multiplies that cost. It also removes the elasticity argument for cloud in this specific case: you are paying for peak capacity in advance, which is what dedicated hardware does.

It requires a forecast, and the forecast will be wrong — which is why the practice is to provision above it and pair it with a degradation ladder, so that exceeding the plan produces reduced quality rather than failure.

The trade is a known, bounded cost against an unbounded reputational and revenue risk during a moment the organisation has usually spent heavily to create. For a scheduled, marketed event the trade is almost always correct. For unpredictable traffic it is the wrong tool entirely — autoscaling exists for that case and works well.

Interview question

"We have a product launch at 10am with an unknown but large audience. Tell me exactly what you provision and when, what you warm, and then tell me the three dependencies you expect us to have forgotten."