A launch day does not fail slowly. It fails all at once.
Capacity planning assumes traffic arrives at a rate. On-sale moments, campaign launches, exam results and appointment windows do not arrive at a rate — they arrive at an instant. The application does not degrade politely: the connection pool fills, the database queues, response times climb, and users refresh, which doubles the load that caused the problem in the first place.
The usual answers make it worse. Autoscaling adds instances after the spike has already landed and after the database is already the bottleneck. Rate limiting refuses requests — which, to a customer who queued for a concert ticket, is indistinguishable from the site being broken. Both leave the same impression: the moment you most wanted to be ready, you were not.
A waiting room changes the shape of the problem. The crowd is not refused and not dropped; it is ordered. The application serves the number it can serve well, everyone else holds a place with a position and an estimate, and the platform admits the next visitor the moment a place opens.
Our approach
The queue runs on the delivery platform, in front of the application, so it is standing up when the application is already at its limit — and no application code is involved in admitting, holding or releasing anyone.
A ceiling the application can actually serve
Set the maximum number of visitors allowed inside a published service at one time. The number comes from what the application demonstrably handles well, not from what the hardware can theoretically pass.
A gate on the rate of arrival, not only the size of the crowd
A separate ceiling caps how many new visitors may enter per minute. This is what protects a backend that survives a large steady population but collapses when ten thousand people arrive in the same second.
Monitor mode — the capacity is found before the event
Run the waiting room in monitor mode and it counts what would have happened without holding anyone back. You size the queue against your own traffic, on an ordinary day, and arrive at the event with a number you trust instead of one you guessed.
Verified bots do not take a place in the queue
Verified search engines and monitoring probes are recognised and exempted, so indexing and uptime checks continue during the event and no seat is spent on traffic that was never going to buy anything.
Capabilities
Everything below is configured per published service from the same screen as the rest of the traffic policy, and every change takes effect by hot reload — including during the event.
Maximum concurrent visitors, per published service
Different applications have different limits, and one appliance can run different waiting rooms for each of them at the same time. The ceiling is a property of the service, not of the box.
New visitors per minute — surge protection
The arrival gate is independent of the concurrency ceiling. A pool that is comfortable with 20,000 people inside can still be destroyed by 20,000 arriving at once; this is the control that separates the two cases.
Conditional waiting pages — only where it matters
The queue is applied by condition, so checkout and ticket paths can be protected while the catalogue, the help pages and the status page stay open. A visitor waits for the thing that is scarce, not for the whole site.
Position and estimated wait, shown to the visitor
A queue without a number is indistinguishable from a hang. The waiting page shows where the visitor stands and how long it is likely to take, which is the difference between waiting and leaving.
The place is held — refreshing does not cost it
The position is bound to the visitor's session, so a refresh, a lost connection or a switch from mobile data to Wi-Fi does not send anyone back to the end of the line. Refresh storms stop being self-inflicted damage.
Your own waiting page
The page is a template you control — your brand, your language, your message — served by the platform even while the application behind it is fully occupied.
Admitted the moment a place opens
As sessions end, the next visitors are released automatically. Nobody is waiting on a timer that has stopped matching reality.
Live visibility while the event runs
Queue depth, admissions per minute, average wait and abandonment are on screen as the event happens, so the decision to raise or lower the ceiling is made on evidence rather than on the phone.
Operational depth
A waiting room is only as good as its behaviour in the awkward cases — a failover mid-event, a bot fleet in the queue, a visitor on a flaky connection.
The queue is on the platform, not in the application
No agent, no library, no code change and no separate queue service to operate. The application never learns that a waiting room exists; it simply never sees more traffic than it can serve.
Fair order, bound to the session
Admission is first come, first served, and the position travels with the visitor's session rather than with an IP address — so a corporate NAT, a mobile carrier CGNAT or a shared office line does not put everyone behind one another.
It composes with the rest of the protection set
Bot scoring runs before the queue, so automated traffic is dealt with instead of being queued. Rate limiting still applies to whoever is inside. The waiting room manages the honest crowd; it is not asked to be a security control.
Survives a failover
Queue state is replicated across the cluster, so a node failure during an on-sale does not reset the line. The event continues on the surviving node with everyone's position intact.
Behaviour on refresh, new tabs and shared devices
A second tab joins the same place rather than taking a second one. Explicit rules cover session expiry and abandonment, so places left by visitors who walked away are returned to the queue instead of being held forever.
Turned on and off during the event
The whole feature is a hot-reload change. It can be enabled minutes before an on-sale and disabled the moment the peak passes, without dropping a connection or restarting anything.
When to use it
On-sale moments and ticketing
Concerts, matches and travel sales concentrate a year's traffic into ninety seconds. The waiting room turns an unservable spike into an orderly line, and every visitor keeps a place they can see.
Product launches and campaigns
A campaign that works is indistinguishable from an attack at the network layer. The waiting room lets marketing succeed without asking infrastructure to absorb the whole success in one second.
Public-sector application windows
Exam results, tax deadlines and appointment openings are announced to an entire population at a published minute. A queue with a visible position is also the fairest answer citizens can be given.
Payday and month-end peaks in banking
Predictable, repeated peaks do not justify permanently sizing for the worst hour of the month. The waiting room covers the peak while the platform stays sized for the ordinary day.
Frequently asked questions
How is this different from rate limiting?
Does the application need to be changed?
How do we choose the right concurrency number?
What happens if a visitor refreshes or loses connection?
Will search engines and monitoring get stuck in the queue?
What happens to the queue if a cluster node fails during an event?
Be ready for the minute that decides the quarter
A concurrency ceiling, an arrival gate and a branded queue — configured per service, sized in monitor mode before the event. Let us set it up on your own traffic.