Section 8: Three Million at the Door - Deep Dive: The On-Sale & the Virtual Waiting Room

Executive Summary: Section 7 made a single hold correct. This section keeps 3,000,000 fans away from it until the backend can serve them. A signed queue token, issued at the edge, carries each fan's place in line, so the edge answers 100,000 status polls a second without the origin. A waiting-room controller reads a histogram of arrival timestamps and moves one number so about 67 shoppers a second cross it. Each tick admits only as many fans as there are vacancies under the 20,000-shopper cap, and a feedback loop cuts the rate when hold latency breaks its SLO. The lesson: you can't scale past a 150× flash crowd; you admit it at the rate the system can serve.

Why Not Just Autoscale

The interviewer goes for the obvious move first.

Interviewer: "Everything behind the gateway is stateless. Put it on autoscaling and let the crowd in."

You: "Three things break. First, size: 3,000,000 fans at about one request a second each is 3,000,000 requests/s against a design load of 20,000, which is 150×. Second, the part that matters doesn't scale. Every hold for E-7781 lands on one show partition, because that's how we partitioned. More stateless servers just send more contention into the same rows. Third, fairness. With no queue, the seats go to whoever has the fastest script and the most tabs open. And autoscaling reacts in minutes, while 2,000,000 people arrive in the first 60 s."

Interviewer: "Fine. Then a simple FIFO: a counter hands out position numbers."

You: "That's 33,000 increments a second on one stateful counter on the critical path. If it fails, we've lost everyone's place. I want the queue state to live in the fans' own tokens, with only an aggregate on the server."