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.
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Queue-Based Scale Trigger operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it 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.
Independent corroboration: The frozen evidence defines Queue-Based Scale Trigger as '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', so its operative form is Control, Automation & Runtime.
Nearest alternative: Monitoring, Sensing & Alerting — Queue-Based Scale Trigger includes features of ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Autoscaling compute capacity from queue depth or wait time is a distributed-systems and cloud-operations technique.
Related originating lineages:
- Operations Research — Queueing models materially explain backlog thresholds and capacity needs.
- Systems Thinking & Cybernetics — High and low water marks implement feedback with hysteresis.
Review outcome: Independent reviewer agreement; high confidence.
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] John D. C. Little. “A Proof for the Queuing Formula: L = λW”. Operations Research. 9(3): 383–387 (1961). Proves that average queue population equals arrival rate times average time in the system, allowing a wait-time bound to be translated into a backlog threshold at a given arrival rate. registry ↩ Show verification details
SupportedVerified against the publisher's abstract
Little's 1961 proof establishes L = λW: mean queue length equals arrival rate times mean time in system.
“It is shown that, if the three means are finite and the corresponding stochastic processes strictly stationary, and, if the arrival process is metrically transitive with nonzero mean, then L = λW.”