Queue-Based Scale Trigger¶

Sensing-and-trigger monitor — instantiates Elastic Capacity Scaling

Uses backlog itself — queue length, wait time, or work-in-progress — as the demand signal, firing add and remove decisions when the queue crosses set high and low water marks.

Queue-Based Scale Trigger makes the accumulating backlog itself the load signal. Rather than reading a rate (arrivals, utilization) or a forecast, it treats queue depth, wait time, or work-in-progress as the truest evidence that capacity is short — the queue is growing — or surplus — the queue is draining to empty — and sets the high and low marks that fire scaling. It is the sensor and trigger of the loop, not the actuator: it decides when to add or remove, and hands the act itself to another mechanism.

Example¶

A fulfillment center's pick-and-pack floor releases orders into a work queue; the number of unreleased orders (WIP) is the signal. When the backlog crosses ≈200 open orders, the shift lead opens another pick line; when it drains below ≈40, that line closes. Because a queue integrates the gap between how fast orders arrive and how fast they're worked, it rises before any individual picker looks busy and falls before anyone looks idle — so it leads both the overload and the slack. By Little's Law, queue length, arrival rate, and average wait are linked,^[1] so a wait-time promise ("no order waits more than ≈30 minutes") converts directly into a backlog threshold. The very same queue read-out doubles as the overload/underutilization monitor: a persistently deep queue flags chronic under-capacity; a chronically empty one flags standing waste.

How it works¶

The signal is a stock (accumulated backlog), not a rate — which is why it captures the integral of the supply/demand mismatch and tends to lead utilization.
High and low water marks, with a deliberate gap between them, translate backlog into add / hold / remove; the gap is the hysteresis that rejects noise.
Read over time, the same backlog series is the overload-and-underutilization record — no separate instrument needed.

Tuning parameters¶

High / low water marks — where add and remove fire; the gap between them sets hysteresis against a fluttering queue.
Signal choice — raw queue length vs wait time vs WIP; wait time ties cleanly to an SLA, length is simplest, WIP suits flow shops.
Averaging window — the smoothing horizon; longer rejects noise but lags a real surge.
Level vs growth-rate trigger — fire on how full the queue is, or on how fast it is filling; the derivative catches a steep ramp earlier than the level does.

When it helps, and when it misleads¶

Its strength is that backlog is often the earliest honest sign of a supply/demand mismatch, and it needs no forecast to work.

It misleads when the queue is a poor proxy for real work: heterogeneous items (one huge job behind many tiny ones) make depth deceptive, and a bounded queue that silently drops overflow hides the very signal it should carry. The classic misuse is setting the high mark so high it never actually fires — so no one is forced to authorize the added cost, and the "trigger" becomes decorative. The discipline is to choose a signal that reflects true work, watch the growth rate and not just the level, and reconcile the threshold against a real service target.

How it implements the components¶

demand_signal — the backlog / wait-time / WIP series is the load signal that drives the loop.
scaling_threshold — the high and low water marks that convert backlog into add / hold / remove.
overload_and_underutilization_monitoring — the same series, over time, flags chronic overload (a deep queue) and standing waste (an empty one).

It does not actuate capacity — that is Cloud Autoscaling in software, or the human and physical siblings; nor does it forecast the peak, which is Scheduled Elastic Scaling.

Instantiates: Elastic Capacity Scaling — it is the sensing-and-trigger core that tells the loop when to move.
Sibling mechanisms: Cloud Autoscaling · Scheduled Elastic Scaling · Modular Capacity Expansion · Expandable Facility Plan · Flexible Staffing Roster · Just-in-Time Resource Provisioning · Self-Service Capacity Deflection · Supplier Release Contract · Surge Team Activation · Demand-Based Budgeting

Notes¶

A queue signal is only as honest as the queue's contents. Where work items differ wildly in size, depth in units is a weak proxy — weight the signal by expected work, or trigger on estimated remaining effort rather than a raw count.

References¶

[1] Little's Law relates the average number of items in a stable queue to the arrival rate times the average time each spends in it — the standard result that lets a wait-time target be converted into a queue-length threshold. It is why a backlog count can stand in for a service-level signal. ↩