Your capacity plan relies on autoscaling to handle traffic spikes. Why might that fail exactly when needed?

What the interviewer is testing

Whether you understand that autoscaling is a control-plane dependency with a reaction time.

Why it fails when needed

Reaction time. Detection interval, scaling decision, instance launch, boot, application start, health check pass, load balancer registration — several minutes end to end. A spike that arrives in 30 seconds is served entirely by existing capacity.

Control-plane dependency. Scaling requires the cloud control plane, which is more complex and less reliable than the data plane, and may be degraded by the same event driving the spike.

Capacity availability. During a widespread event, everyone scales simultaneously and the requested instance types may not be available.

Account quotas, which are sized for normal operation and are a hard stop.

Scaling the wrong thing. The application tier scales; the database, the connection pool, the downstream dependency or the third-party rate limit does not — so scaling moves the bottleneck rather than removing it, and can make things worse by increasing pressure on the constrained component.

Metric lag. Scaling on CPU that is already saturated means scaling begins after latency has already degraded.

What to do instead

Headroom sized for the spike you can anticipate, so existing capacity absorbs it while scaling catches up. Autoscaling handles the sustained change, not the burst.

Pre-scale for known events — a campaign, a product launch, a seasonal peak — rather than relying on reaction.

Scale on a leading indicator such as queue depth or in-flight request count, which rises before latency degrades.

Load shedding as the mechanism that protects the system when scaling cannot arrive in time.

Verify quotas and reserve capacity for the failure case.

What a strong answer adds

Applying the same reasoning to disaster recovery: a plan that provisions capacity in the secondary region at failover time has the same control-plane dependency, at the worst possible moment. Static stability — capacity already running — is the principle that covers both.

Common weak answers

Reducing the scaling cooldown, which does not address boot time. Treating autoscaling as capacity planning.