Surge Queue¶

Governed waiting-line process — instantiates Intermittent Burst Absorption

Holds burst arrivals in an ordered, governed waiting line — with triage, aging, escalation, and release rules — so the primary process serves them in priority order instead of collapsing under the immediate load.

A Surge Queue absorbs a spike by holding arrivals in an ordered, governed waiting line and releasing them to the primary process at a rate it can handle. Unlike a plain buffer, it doesn't just store excess — it orders it: items enter with a priority, they age (so nothing waits forever), they can escalate, and they're released under explicit rules. And unlike a shedding gate, its default is to hold and serve rather than reject. What makes it this mechanism is the combination of holding, prioritized ordering, and visibility in one structure: the queue is where the burst waits, where the order of service is decided, and where the growing backlog is made plainly countable so no one mistakes a full queue for a handled one.

Example¶

A national passport office runs smoothly most of the year but is hit every spring by a surge of applications from people planning summer travel — far more than caseworkers can process the day they arrive. Rather than let applications pile in an undifferentiated heap (or turn people away), the office runs a surge queue: applications enter a tracked processing queue tagged by priority — imminent-travel and expedited-fee cases ahead of routine ones — and age within their band, so a routine application that has waited a long time escalates rather than languishing behind an endless stream of newer expedited ones. Caseworkers pull from the front at their sustainable rate; the queue's dashboard shows exactly how many cases wait, in which bands, and how long, so the backlog is visible and staffable rather than hidden. The spring spike is absorbed as an orderly, prioritized wait instead of a collapse — and when volume falls, the queue drains back to empty.

How it works¶

The distinguishing content is the governance layered on top of mere holding:

Admit and hold arrivals in a structure sized for the burst, decoupling arrival rate from the primary's service rate.
Order by priority, not just arrival — items carry a priority that decides service order, so what matters most is served first under load.
Age and escalate — waiting time bumps priority so low-priority items don't starve forever; breached limits escalate, preventing the queue from becoming a graveyard.
Release under rules — pull to the primary at its sustainable rate, and define what happens at capacity (spill to overflow, or shed the lowest band).
Expose the backlog — depth, age, and composition are continuously visible, so the accumulating wait can be seen and acted on rather than silently compounding.

Tuning parameters¶

Queue capacity — how many items it will hold. Deeper absorbs bigger bursts but lets wait times grow long; shallower keeps waits honest but spills or sheds sooner.
Ordering policy — strict priority, weighted fairness, or FIFO-within-band. Strict priority serves the most urgent first but can starve the rest; fairness spreads service at some cost to the top.
Aging / anti-starvation rate — how fast waiting raises an item's priority. Faster protects the long-waiting; slower keeps high-priority items firmly ahead.
Release rate — how fast items flow to the primary, bounded by what the primary can absorb without itself tipping over.
Overflow-at-capacity behaviour — what happens when the queue is full: block, spill to an overflow path, or shed the lowest band — setting the queue's worst-case guarantee.

When it helps, and when it misleads¶

Its strength is orderly absorption with prioritization and visibility: the burst becomes a managed wait in which the most important work is served first, nothing starves, and the backlog is countable — far better than a plain buffer's blind FIFO or a shedding gate's outright loss when the arrivals differ in value.

The failure mode is the queue that hides a structural deficit. Because it will hold almost anything, a surge queue can absorb a sustained imbalance for a long time — wait times growing quietly — so "the queue is up, we're fine" masks the fact that arrivals persistently exceed service and the backlog will never drain.^[1] Deep queues also add latency for everyone and can produce head-of-line effects where a stuck item blocks those behind it. The classic misuse is treating an ever-growing queue as success because nothing is being rejected, while the effective wait becomes so long that held work is dead in practice. The discipline is to bound the queue, watch that it returns toward empty between bursts, and treat persistent growth as a signal to add capacity or shed — not as absorption working.

How it implements the components¶

temporary_holding_capacity — the queue is the short-term store where burst arrivals wait, decoupling arrival from service.
priority_policy — its ordering, aging, and escalation rules decide who is served first under load, so scarce capacity goes to what matters most.
backlog_visibility — the queue's depth, age, and composition make the accumulating backlog continuously countable, so it can't hide inside the process.

It applies a priority order but does not author the clinical/business rules for *how items are ranked — that is Triage Protocol — and it holds-and-serves rather than capping inflow (Rate Limit with Burst Allowance) or storing without order (Burst Buffer).*

Instantiates: Intermittent Burst Absorption — it is the ordered, visible holding structure that absorbs a spike while preserving priority.
Consumes: Triage Protocol supplies the ranking rules the queue enforces.
Sibling mechanisms: Triage Protocol · Burst Buffer · Rate Limit with Burst Allowance · Overflow Channel · Elastic Capacity Scaling · Peak Response Reserve · Backup Staffing Pool · On-Call Response Rotation · Incident Surge Team · Flash Crowd Playbook · Post-Burst After-Action Review

References¶

[1] Little's Law (average wait = queue length ÷ throughput) makes the trap precise: if arrival rate persistently exceeds service rate, queue length — and therefore wait — grows without bound. A queue absorbs bursts, where arrivals temporarily exceed service; it cannot fix a standing deficit, it only delays and disguises it. ↩