A virtual waiting room built for drops, not for Black Friday

What a virtual waiting room actually does

When more people arrive at once than your store can serve, something has to give. Without a queue, what gives is the store: the database saturates, checkout times out, and the people who would have bought get an error page instead. A virtual waiting room puts a controlled door in front of that. Arrivals are held in one line, given a position, and released into the store at a rate you set.

Two things follow from that, and only one of them is usually advertised:

• Your store never sees more traffic than it can handle. This is the part every vendor sells.
• You decide who gets in, and in what order. This is the part that decides whether a drop is fair, and it is barely discussed.

When you need one, and when you don’t

You need a waiting room when demand arrives in a spike rather than a wave. A queue is worth nothing on a normal trading day and indispensable at noon on a Friday when a limited run goes live.

The more useful question is which problem you have:

• A capacity problem. A big catalogue, sustained heavy traffic, a Black Friday that runs for hours. You want traffic smoothed. Almost any waiting room does this, including the ones bundled into a CDN, and the cheapest adequate option is the right one.
• A scarcity problem. 500 units, 20,000 people, and it is over in minutes. Smoothing traffic does not help you, because the constraint is not your servers — it is the stock. What matters is allocation: who gets the thing.

These need different tools, and the difference shows up in one specification.

The specification that decides a drop

Not concurrency. Admission rate — how many people per minute the queue lets through.

Concurrency is how many people can wait at once, and it is the axis nearly every vendor prices on, so it is the axis buyers compare. But for a drop it is close to irrelevant: it tells you the waiting room will not fall over, which was never in doubt. What decides the outcome is the rate.

Work through it with real numbers. You have 500 units.

• At 200 admissions a minute — the documented minimum for a Cloudflare waiting room, which cannot be set lower — your drop is effectively over in two and a half minutes. Whoever’s script was fastest at the door took it.
• At 60 a minute — the cap on CrowdHandler’s entry tier — a 2,000-unit drop takes 33 minutes, and you cannot speed it up or slow it down.
• At a rate you choose, you can trickle stock out over an hour, or open the gates, and change your mind between drops.

Before you compare prices, find the admission-rate number in each vendor’s documentation. On our pricing page it is a column, it says “you set it — no floor, no cap”, and it says that on every plan including the cheapest.

First-come-first-served is a rule, not a guarantee of fairness

A queue that admits in arrival order does exactly what it says. Nobody jumps the line. And if arrival order is set by who automated the fastest, the fair rule produces an unfair result — the line is honest and the outcome is still that resellers got the stock.

There are two answers to that, and a serious waiting room offers both:

• Screening at the door, so scripted traffic is not what is arriving first.
• Removing the reward for arriving first at all. In a presale drop, a cohort registers over a window with no position assigned, and every position is drawn at random the moment the drop starts. Registering in the first millisecond and registering 47 minutes later are worth the same.

An ordinary queue here is first-come-first-served by ticket sequence, the same as everyone else’s. The random draw is what a presale does, and it is standard rather than an enterprise add-on. Queue-it also ships randomisation at event start; we are not unique in having it, and we are unusual in explaining exactly how it works.

Where the waiting room runs matters more than it sounds

Most waiting rooms sit in front of your store. You point your domain at the vendor, or switch on a feature inside the CDN you already use, and from then on every click your customers make passes through their infrastructure before it reaches yours. It works — and it makes your store downstream of somebody else’s bad day.

This one is built the other way around. Queue admission and pass issuance run in our cloud; a small open-source adapter runs in yours and does the enforcing, checking a signed, single-use pass locally with no network call. No reverse proxy. No DNS change. Your origin never moves, and none of your shoppers are routed through us.

The consequence worth stating plainly: if we are unreachable, your store keeps selling. The adapter fails open by design and keeps a durable last-known-good policy, so gating survives us being down. That is the opposite of the usual arrangement, where the vendor’s outage is your outage.

What to ask a vendor before you buy

1. What is the minimum admission rate, and can I change it during a drop? If it is not in their documentation, ask. If the answer is a floor, they cannot run a small drop.
2. Does my traffic route through you? If yes, their availability is now your availability.
3. What happens if your service is unreachable? “Fails open” should be a documented behaviour, not a hope.
4. Is the enforcement code something I can read? Ours is MIT-licensed and installs in shadow mode by default — it logs what it would have done and enforces nothing until you switch it on.
5. What costs extra? In this category, custom branding, reporting and bot defence are routinely separate line items. Queue-it’s own UK G-Cloud rate card prices them as an upgrade that costs 118% more at identical traffic volume.

Where we are honest about not fitting

If you have a sustained-load problem across a large catalogue rather than a scarcity problem, a CDN waiting room is the right tool and its 200-per-minute floor is a sensible default rather than a defect. If you need priority or invite codes today, we do not have them. Shoppers always see their position. Two optional, per-store extras are off until you turn them on: an estimated wait at the current pace (hidden while the line is paused, never a promise) and a countdown to a scheduled presale draw.

That list is short on purpose, and it is on this page rather than three emails into an evaluation.