A queue is two numbers: how many users can be inside at once, and how many new users may enter per minute. Once traffic exceeds them, newcomers wait, and when people inside finish or go idle, space opens and the next visitors get in. That mechanism works after the purchase too. A restock drop, a returns window after a big sale, or an exchange rush for a sold-out size all create the same burst, and the same fairness question: who got here first, and can anyone prove it. The answer is the cookie that holds the first-arrival timestamp, and the queue that honors it.
The queue is two numbers, and the numbers work after checkout
A waiting room is simpler than it looks. The site owner sets two numbers: how many users can be inside at once, and how many new users may enter per minute. Once traffic exceeds them, newcomers go to the waiting room, and when people inside finish or go idle, space opens and the next visitors get in. That is the whole mechanism, and it applies anywhere demand exceeds capacity, not just at checkout. A restock drop is a checkout problem in reverse: the same crowd, the same burst, the same bots, arriving for a product that sold out an hour ago.
The returns window after a big sale is the same shape again. Thousands of buyers come back at once to exchange a size, return a gift, or claim a restock, and the store's returns portal, exchange flow, and customer service queue all face the same crush the checkout faced on launch day. A store that queues only the purchase and leaves the return unguarded has protected the money and abandoned the customer. The queue belongs wherever the crowd forms, and after a drop, the crowd forms at the returns desk.
Related reading on this site: Home and Queue Analytics: The Three Numbers That Tell You the Drop Is Oversold cover the neighbouring problems in more depth.
Your place in line lives in a cookie, not on the server
Where is a shopper's place in line stored? Not on the server, but in the browser. In a first-in-first-out waiting room, the queue gives each visitor a cookie, and that cookie holds the time they first reached the waiting room. That timestamp is the ticket number. The waiting page refreshes itself every 20 seconds to update the estimated wait, and refreshing in the same browser does not change the number, because the order comes from the cookie's first-arrival time and refreshing does not delete the cookie.
What sends a shopper back is coming in fresh without that cookie: a private window, another browser, or cleared cookies. The new browser has no ticket, so it gets a new, later timestamp. That is the detail to tell customers before a restock drop, because the shoppers who open the queue in three browsers to hedge their chances are hurting themselves: two of those browsers have later timestamps, and the one that counts is the earliest. A store that explains the cookie rule in advance gets fewer angry messages during the drop, and the messages it gets are from people who opened a private window and lost their place, which is a fixable mistake.
FIFO is not always the fairest answer for a scheduled drop
First-in-first-out feels fair, and for a store that opens a queue when traffic spikes unexpectedly, it is. But for a scheduled event, a product drop or a restock with an announced time, FIFO has a flaw: the sale effectively starts when the queue starts, not when the sale starts. A visitor can open the queue page an hour early and wait productively while the sale is still closed, and the race of milliseconds is won by people with fast connections and by bots. Queue-it, which runs more than 90 million visitors through its waiting rooms every day, recommends a scheduled-event waiting room that combines randomization with first-in-first-out for exactly this reason.
The fix is a pre-sale page with a countdown clock. Viewers on the pre-sale page go through to the queue when the sale opens, optionally with a random position, so that everyone who arrived before the sale opened is treated equitably. That is the fairness argument for the post-purchase queue too: a restock drop with an announced time should randomize the early arrivals, not reward the fastest connection. The four queueing methods are first-in-first-out, random, passthrough, and reject, and the choice between the first two is a choice about what fairness means for that event. Pick it on purpose, announce it before the drop, and the queue becomes a feature instead of a complaint.
Frequently asked questions
Does refreshing push me back in an online queue?
No, in a first-in-first-out waiting room. Your place is stored in a cookie holding your first-arrival timestamp, and refreshing in the same browser does not change it. Opening a private window or a different browser gives you a new, later timestamp.
What are the two numbers that run a waiting room?
How many users can be inside at once, and how many new users may enter per minute. Once traffic exceeds them, newcomers wait, and space opens as people inside finish or go idle.
Why is first-in-first-out not always fair for a drop?
Because the sale effectively starts when the queue starts, not when the sale starts, so the fastest connections and bots win the race of milliseconds. A scheduled-event waiting room combines randomization with first-in-first-out so early arrivals get an equal shot.
Can a queue help with returns and restocks, not just checkout?
Yes. A restock drop, a returns window after a big sale, or an exchange rush for a sold-out size all create the same burst and the same fairness question. The queue belongs wherever the crowd forms, and after a drop the crowd forms at the returns desk.