Admission Queue

When arrivals exceed capacity, the system's options are to serve everyone badly, to fail an arbitrary subset, or to admit people at a sustainable rate and tell the rest to wait. The third is almost always the best outcome for users and is the only one that keeps the system in a serving state rather than a collapsed one.

An admission queue makes this explicit. Arrivals receive a position and an estimate; the system admits at a rate derived from measured capacity; the backend never sees more load than it can handle.

Why it matters

Overload without admission control is not "slower for everyone" — it is failure for nearly everyone. Queues grow, timeouts fire, clients retry, and the system spends its capacity producing errors. A queue converts that into a predictable wait and a successful experience on the other side of it.

It is also the fairness mechanism. Without a queue, admission is won by whoever retries most aggressively — which means bots, and users with better connections and faster devices. A queue with a token issued on first arrival makes the ordering explicit and defensible, which matters commercially and sometimes legally.

Implementation patterns

• A token issued at first arrival, establishing position, held across disconnection. A queue that loses a place when the network blips becomes its own failure mode and generates more retries than it prevents.
• Honest communication of position and estimated time. An opaque queue is indistinguishable from a hang and produces the same support load as an outage; the estimate does not need to be precise, it needs to exist and to move.
• Admission rate derived from measured downstream capacity, adjusted continuously, rather than a fixed number chosen beforehand.
• The queue itself on separate, simple, massively scalable infrastructure — typically static assets plus a lightweight token service — since it must survive the load that the main system cannot. A queue that fails under load is a spectacular and public failure.
• Bot mitigation before the queue, or the queue is filled by automation and the fairness property is lost.
• Signed, single-use admission tokens so a place cannot be shared, sold or replayed.
• Prioritisation where it is legitimate — returning users mid-journey, or users already in checkout — with the policy stated rather than hidden.
• A tested, load-tested queue, exercised at real arrival rates before the event.

Industry example

Virtual waiting rooms became widely known through high-demand ticket on-sales, where demand can exceed supply by an order of magnitude and where the 2022 Taylor Swift Eras Tour on-sale is the most-analysed case: an arrival volume many multiples above forecast, heavily contaminated with automated traffic, against a fixed and small inventory.

The general lessons from that episode are architectural rather than specific: the queue must be sized and tested for the arrival rate rather than the inventory, bot mitigation must precede the queue or the queue allocates fairness to bots, and the messaging must be honest, because a queue that promises access it cannot deliver damages trust more than a plain refusal would have.

Failure scenarios

• No queue at all, so overload becomes failure and retries dominate.
• The queue sharing infrastructure with the system it protects, so both fail together.
• Places lost on disconnection, generating retries and destroying the fairness property.
• Opaque waiting, with no position or estimate, which users interpret as a broken site.
• Bots in the queue, converting a fairness mechanism into an automated advantage.
• Admission rate set statically and unrelated to actual downstream capacity, so the system is either starved or still overloaded.
• Admitted users finding nothing left, which is the worst outcome — a queue must not promise what the inventory cannot honour, and the messaging must reflect that.
• Never load tested, so the queue's own capacity is the first thing to break.

Trade-offs

Queues make waiting visible, which is honest and is also a worse-looking experience than a fast site — some users will leave, and the abandonment is measurable in a way that a hidden failure is not. There is a real commercial temptation to admit more people than the system can serve, and it produces worse outcomes.

They also add infrastructure and a whole class of edge cases — token expiry, place recovery, prioritisation policy, abuse — for a mechanism used only during exceptional events. That maintenance burden is easy to defer and disastrous to discover missing.

The trade is visible waiting and permanent infrastructure in exchange for a system that stays in a serving state under any arrival rate. For anything with scheduled demand spikes it is close to mandatory; for steady traffic it is machinery that will never engage, and simple load shedding is the proportionate answer.

Interview question

"Two million people will hit our on-sale at 10:00 and we can serve fifty thousand concurrent. Design the front door — then tell me what happens to someone's place when their train goes into a tunnel, and how you stop the queue from being full of scripts."