Virtual waiting room

At an onsale, millions of people try to buy at once. Even when seats are already gone, the hold API still takes the full stampede. A virtual waiting room sits in front of booking. It lets people in at a rate the system can sustain, and it keeps everyone else in a queue on a separate, cheap path.

The big idea

Think of a theme park queue with numbered tickets. The park lets in groups as rides have room, and nobody can skip the line by walking past the entrance. The park does not need to see every guest's face. It only checks the ticket.

The picture breaks online, where a ticket can be copied or forged. That is why the admission token is signed.

Walking through it

Start with the capacity arithmetic. Two million people compete for 50,000 seats. If each admitted user stays in the booking flow for about 90 seconds, and the hold service can support 10,000 concurrent sessions, then new admissions should run at about:

10,000 concurrent sessions / 90 s per session ≈ 111 new users per second

Add some headroom for bursts, and that is the admission rate the controller aims for. Interviews often ask you to separate three numbers: the admission rate, the concurrent sessions and the holds per second.

The flow works like this:

1. A user joins the queue, or gets a random position if they arrived before the onsale.
2. The admission controller lets users in at the target rate.
3. An admitted user receives a signed, short-lived token that binds their user ID, the event, an expiry time and a signature.
4. The booking API rejects any hold request without a valid token.
5. Queue position is served from the edge, so polling does not reach the origin.

Feedback keeps the rate honest. If hold latency or error rate rises, lower the admission rate. If the system is idle and the queue is long, raise it.

Fairness

Ordering the queue by who refreshes fastest rewards bots. A common policy is to give everyone who joined before the onsale a shuffled position, and add later arrivals behind them. Fairness is a product choice, but the token design enforces it. Tokens must be unforgeable and tied to one user and one event.

Common mistakes

• Queueing by refresh speed. Scripts win, and real fans lose.
• Unsigned or unbound tokens. A forged token opens the hold path, or a token from one show works for another.
• Letting queue polling hit the origin. Serve queue status from the edge.
• A fixed admission rate with no feedback. Load changes during a sale, and the rate must follow it.

Check yourself

1. Using the numbers above, what admission rate keeps 10,000 sessions of 90 seconds each in balance?

Answer: About 111 new users per second, since 10,000 ÷ 90 ≈ 111.

2. Why bind the token to both the user and the event?

Answer: So a token from one buyer or one show cannot be reused by someone else or for a different event.

Key takeaways

• Match admission to what the backend can sustain, not to raw demand.
• Admitted users get signed, short-lived tokens, and the booking API rejects requests without one.
• Fairness is a policy. The queue has to enforce it.
• Adjust the admission rate from hold latency and error rates.

Further learning

Next, see how payment is ordered around the seat claim in authorize, commit, capture.