Capacity-Aware Reconnect Queue¶

Admission-control queue — instantiates Synchronized Release Dampening

Holds a stampede of reconnecting clients in a buffer and admits them only as fast as the recovering resource's measured capacity allows, pushing the wait back onto the callers instead of onto the choke point.

A Capacity-Aware Reconnect Queue sits between a reconnect storm and the resource that is trying to recover, and admits the returning clients at a rate slaved to a live capacity signal rather than a fixed cap. When a service comes back after a restart, every dropped client tries to reconnect at once — and that recovery wave is often what kills the service a second time. The queue's defining move is that it is closed-loop and self-relieving: it reads how much headroom the healing resource actually has right now, opens the gate only that wide, and tells everyone else — explicitly — to wait, so the backlog sits with the callers instead of drowning the choke. It consumes a recovery signal; it does not produce one.

Example¶

A real-time collaboration app (think a shared document editor) runs its live sessions through a regional gateway. The gateway restarts, and roughly 250,000 websocket clients drop and immediately try to reconnect within a few seconds. A naive gateway lets them all back in, the session and auth services behind it are instantly overwhelmed, and the "recovery" becomes a second outage. A capacity-aware reconnect queue fronts the gateway instead: it starts admitting reconnections slowly, reads the session service's live headroom, and ramps the admission rate up only as that headroom grows. To every client it has not yet admitted it returns an honest retry-after ≈ N seconds hint, so the clients stop hammering and wait quietly. The fleet trickles back over a few minutes instead of colliding in a few seconds, and the session service climbs back to health under a load it can actually carry.

How it works¶

Buffer the waiting population. Give the reconnecting clients a defined place to wait so their number is bounded and known, not an unbounded spin.
Read a capacity signal and set the rate from it. Admission is a function of the resource's current headroom — starting conservative and ramping as health recovers — rather than a static limit.
Emit backpressure upstream. Return explicit retry-after / slow-down responses so callers hold off, moving the wait to the edge instead of the core.

The distinguishing property is that the admission rate tracks recovery: a fixed rate limiter cannot tell a healed resource from a sick one; this can.

Tuning parameters¶

Initial rate and ramp slope — how cautiously admission starts and how fast it opens; too steep re-collapses the resource, too shallow needlessly prolongs the outage.
Capacity signal and smoothing — which health metric drives the rate and how much it is filtered, trading responsiveness against jitter in the signal itself.
Backpressure strength — advisory retry-after versus hard rejection, depending on whether callers can be trusted to honor a hint.
Queue bound and overflow policy — how large the buffer may grow and what happens past it (shed, reject, redirect) before the backlog becomes invisible debt.

When it helps, and when it misleads¶

Its strength is that it turns a reconnect storm into a governed drain and adapts to how fast the resource is actually healing, which is exactly what keeps recovery from becoming a second incident. Its signature failure is backlog displacement: the choke survives, but the obligations pile up upstream where they are hard to see, and if callers ignore the backpressure the queue degrades into a distributed busy-wait.^[1] A poor capacity signal is the other trap — read it wrong and the gate ramps too fast (re-collapse) or too slow (a self-inflicted extension of the outage). The classic misuse is leaving the throttle clamped down after recovery, where it quietly becomes a permanent hidden cap. The discipline is to bound the queue, make the backpressure honest and observable, and drive the rate from a real capacity signal rather than a guess.

How it implements the components¶

waiting_population_boundary — the buffer is the boundary: it defines and holds the set of clients waiting to reconnect, making the herd countable instead of unbounded.
admission_gate — it meters entry to the recovering choke, but keyed to live capacity rather than a fixed rate.
upstream_backpressure_channel — the retry-after / slow-down responses are the channel that pushes the wait back onto callers so their retry behavior relaxes under pressure.

It does not detect whether capacity has recovered — it consumes that signal from Half-Open Circuit Probe; nor does it decorrelate scheduled wakeups (Jittered Wakeup Timer) or partition the population into planned waves (Cohort-Based Reactivation).

Instantiates: Synchronized Release Dampening — it is the admission stage that lets a recovering resource re-absorb its clients at a survivable rate.
Consumes: Half-Open Circuit Probe — the recovery / health signal whose value sets the admission rate.
Sibling mechanisms: Half-Open Circuit Probe · Token-Bucket Admission Gate · Semaphore-Limited Release · Exponential Backoff with Jitter · Cohort-Based Reactivation

References¶

[1] Backpressure is the established term for a downstream resource signaling upstream producers to slow down so load stays within what it can serve. It is named here as a real control-flow concept; the failure the mechanism must watch for — obligations accumulating upstream out of view — is the well-known hazard of applying backpressure without also bounding the queue that absorbs it. ↩