Elastic Capacity Scaling¶

Automated scaling tool — instantiates Intermittent Burst Absorption

Watches a load indicator and automatically adds capacity when it crosses a threshold, then removes it when the burst subsides — matching supply to demand in near-real time.

Elastic Capacity Scaling is a closed control loop that sizes capacity to demand while the demand is happening. It watches a live indicator — queue depth, CPU, request rate, occupancy — and when that indicator crosses a configured threshold it provisions more of whatever is scarce (compute, bandwidth, seats), then de-provisions once load falls back. What makes it this mechanism is the automation of the sense-and-add cycle: it is not a stored buffer that holds excess and not a bench a manager decides to call in, but a controller that continuously reads the burst signal and moves real capacity up and down to track it, so the system can be sized for the average yet still meet the spike.

Example¶

An online retailer runs its site on a handful of servers that comfortably carry normal traffic. Then it launches a one-day flash sale promoted to millions, and requests jump tenfold within minutes — a textbook intermittent burst. Instead of pre-buying ten times the servers to sit idle the rest of the year, the retailer configures autoscaling: a policy watching average request latency and CPU across the fleet. As the sale opens and latency climbs past the set threshold, the platform launches additional server instances automatically — no human in the loop, no ticket filed — until the fleet is large enough to hold latency down. When the sale ends and traffic drops, the scaler tears the extra instances back down so the retailer stops paying for them. The site absorbed a 10× spike it never provisioned for, because the controller detected the crossing and matched capacity to it in minutes.

How it works¶

The distinguishing content is the loop itself and how it avoids over-reacting to noise:

Sense a live indicator that moves with the burst — the metric must lead or track the overload, not lag it, or capacity arrives too late.
Compare against a scale threshold with hysteresis: scale up at one level, down at a lower one, so brief flutter around a single line doesn't cause thrashing.
Provision real capacity — spin up instances, add workers, open lanes — accepting whatever start-up delay ("warm-up") the resource carries.
Scale back down after the burst, releasing capacity so the elastic reserve is available (and unpaid-for) again before the next spike.

Tuning parameters¶

Scaling metric — which indicator drives the loop (latency, queue depth, CPU, arrival rate). The right metric leads the overload; a lagging one scales too late.
Scale-up / scale-down thresholds — where the loop triggers in each direction. Aggressive up-thresholds catch spikes early but over-provision on noise; the gap between up and down sets the hysteresis band.
Step size — how much capacity is added per action. Big steps meet sharp spikes fast but overshoot; small steps are smooth but may lag a steep ramp.
Cooldown — how long the loop waits before acting again, damping oscillation at the cost of responsiveness.
Floor and ceiling — the minimum kept warm and the maximum it may ever provision, bounding both cold-start lag and runaway cost.

When it helps, and when it misleads¶

Its strength is that capacity tracks demand automatically and both ways: the system meets a spike it never sized for, and it stops paying the moment the spike passes — absorption and recovery in one loop, with no human on the critical path.

The failure modes cluster around the control loop. Tuned too tightly it flaps — adding and removing capacity in oscillation as the indicator crosses the line repeatedly, wasting resource and destabilizing the very thing it protects.^[1] It is also only as fast as its slowest new unit: if capacity has a long warm-up, the loop reacts correctly but the spike is over before help arrives. And it scales the bottleneck it can see — add web servers and the database becomes the new wall, so an unwatched downstream can be crushed by the capacity added upstream. The discipline is to give the loop hysteresis and a cooldown, keep a warm floor for cold-start-sensitive spikes, and scale against the true bottleneck rather than the first metric that was easy to read.

How it implements the components¶

burst_detector — the metric watch is the detector: it recognizes when the live indicator has moved from ordinary variation into burst territory.
burst_threshold — the configured scale-up level is the explicit boundary at which ordinary operation gives way to adding capacity.
surge_capacity — provisioning instances, workers, or lanes is the temporary capacity the archetype calls for, added and released on the burst's timescale.

It does not set the governing inflow cap or shed sustained overload — that is Rate Limit with Burst Allowance — nor decide which requests are served first (Triage Protocol), nor hold excess in a store (Burst Buffer).

Instantiates: Intermittent Burst Absorption — it is the automated detect-and-add core, matching real capacity to the spike in near-real time.
Sibling mechanisms: Rate Limit with Burst Allowance · Burst Buffer · Surge Queue · Peak Response Reserve · Backup Staffing Pool · On-Call Response Rotation · Incident Surge Team · Overflow Channel · Triage Protocol · Flash Crowd Playbook · Post-Burst After-Action Review

Notes¶

Elastic scaling detects and adds, but it does not decide what to do with load while capacity is still spinning up. In a sharp spike with slow warm-up, a buffer or queue absorbs the gap and a rate limit or shedding gate bounds the worst case — the scaler is one part of the loop, not the whole absorption design.

References¶

[1] Flapping (or scaling oscillation / thrashing) is the well-known autoscaler pathology where capacity is repeatedly added and removed as the driving metric crosses the threshold back and forth. Hysteresis — separate scale-up and scale-down thresholds plus a cooldown — is the standard corrective, which is why both appear among the dials above. ↩