The Ticketmaster Eras Tour On-Sale: What 3.5 Billion Requests Teach About Admission Control

Ticketmaster’s 2022 Taylor Swift Eras Tour on-sale teaches more than “test a bigger number.” Ticketmaster’s own account reported more than 3.5 billion system requests during the sale, roughly four times the company’s previous peak. It reported more than 3.5 million people preregistered, about 1.5 million people sent codes to join the onsale, and the remaining 2 million Verified Fans placed on a waiting list. Those figures describe system demand and a human access process. They do not describe 3.5 billion human buyers. The testing question that matters is how admission control keeps those populations apart.

Read the source precisely

Ticketmaster says more than 3.5 million people preregistered. About 1.5 million were sent codes to join the onsale, and the remaining 2 million Verified Fans were placed on a waiting list in case tickets remained. Its post says the platform received more than 3.5 billion requests. The account does not show that every request came from a person trying to buy a ticket, and it gives no simple conversion from requests to customers.

That distinction matters. A load plan that turns a request headline straight into “users” invents a workload. Model layers instead: registration demand, queue traffic, purchase sessions, polling, retries, automated traffic, and internal work. State which numbers come from a source and which are hypothetical planning assumptions.

Admission changes the shape of load

An open sale invites an arrival burst at a known minute. A waiting room can absorb that burst by letting only a bounded cohort into the expensive purchase path. Queue pages still create work (polling, session state, and status responses), but they keep the whole population from hitting inventory, checkout, and payment systems at once.

Test that control boundary on its own. Measure queue admission rate, queue response latency, poll frequency, session expiry, and the rate at which admitted users reach inventory. Then measure the protected path with a stable admitted cohort. If you fold every layer into one request total, you cannot see which mechanism carries the risk.

Test the layers, not the headline

Start with a registration scenario that has realistic validation and duplicate handling. Add a queue scenario with a controlled poll interval and jitter. Do not make every client poll on the same second unless a synchronized burst is the question. Build an admitted purchase scenario with stateful inventory and safe synthetic data. Last, run an abuse or bot-like scenario, and only with authorization and explicit isolation.

For each layer, record scheduled and achieved arrivals, response distributions, queue depth, admission decisions, errors, and downstream saturation. A queue that stays responsive while the purchase service fails is a control-plane success and a protected-path failure. A queue that fails open is a safety finding even if the origin stays fast.

Include the failure paths

Admission control needs explicit answers for a slow queue store, an expired token, a user who refreshes, and a client that retries. Does the system keep the position, issue a fresh token, reject the request, or admit work by accident? Test timeouts and partial dependency failures without setting off an uncontrolled retry storm.

Test the recovery boundary too. When capacity returns, do thousands of waiting sessions leave together? A drain policy with a bounded release rate may be safer than an immediate flood. Measure whether the queue, inventory service, and payment path recover independently.

What not to claim

The Ticketmaster source explains its published request, preregistration, code-recipient, and waiting-list figures. It does not give a complete root-cause model for every request, and it does not prove that one technical change would have prevented the event. Keep this article’s inference narrow: the numbers show why admission control and layered workload models matter.

The incident also gives you no license to test a real ticket sale without permission. Use a staging system or an approved production canary with synthetic inventory. The spike test model can reproduce the timing shape safely when the target is yours to exercise.

A test brief for a flash sale

Document the sale minute, registration mix, queue poll behavior, admission rate, protected-path cohort, inventory semantics, bot assumptions, safety ceiling, and stop signals. Link every sourced number to Ticketmaster’s published explanation, and label your own scenarios as hypothetical.

Keep the scenarios separate, and compare them only when their assumptions match. The lasting takeaway is architectural. Demand is not one number, and a queue is not a decorative page. Admission control is a load-shedding mechanism, and its limits, failure modes, and recovery each deserve a test.

The queue’s success criterion should include fairness as well as speed. Positions should not move backward, an expired session should have an explicit outcome, and admission should not bypass the stated policy. These are correctness properties of the load-shedding layer. They protect the purchase path even when demand far exceeds the available inventory.

What the queue test should prove

First, prove that an unadmitted request cannot reach inventory or payment. Then vary the queue poll interval and watch queue-service CPU, session state, and response latency. Test refreshes, expired positions, duplicate tabs, and a client that disappears. You are not aiming for zero queue work. You want bounded, understandable queue work that protects the expensive path.

Next, hold an admitted cohort steady and test purchase capacity. Use synthetic inventory with explicit reservation and release semantics. Check that rejected reservations leave no phantom stock and that a successful order has exactly one durable outcome. Last, test a controlled drain: admit a bounded batch, let it finish, and measure whether the next batch enters without a wave.

These experiments turn the published scale of the incident into engineering questions, without pretending the source supplies a complete workload model. Keep the source link, your assumptions, and the safety approval in the run record.

Use the published figures as context, not as a fixture. Ticketmaster’s request total and its preregistration, code-recipient, and waiting-list figures are sourced observations. Your queue poll rate, admission batch, synthetic inventory, and safety ceiling are test assumptions. Keeping the two apart lets your team learn from the event without claiming to reproduce its full demand or cause.

A review should ask three separate questions. Can the queue hold waiting sessions? Can it admit a bounded cohort? Can the protected purchase path complete its state transitions? Give each question its own scenario and threshold. If one fails, you know which boundary needs a design or capacity change, instead of raising one undifferentiated load number.

Make the admission experiment reversible. Start with synthetic identities and inventory, cap the admitted cohort, and exercise session expiry, refresh, duplicate submission, and a dependency timeout. Watch queue length, admission rate, token issuance, database writes, and downstream calls separately. A queue that stays responsive while token issuance duplicates entries is not healthy. Neither is a purchase API that answers quickly while leaving reservations locked. Define the abort signal before the run, and keep a trace or request identifier for each state transition, so you can inspect correctness without replaying customer traffic. You get a useful engineering lesson and stay within the source incident’s limits.

Report arrival spikes and sustained occupancy separately. A short burst can expose admission locks or connection churn. A longer, lower rate can expose session retention, queue memory, and abandoned reservations. Run the scenarios independently and reset synthetic state between them. For every failed assertion, record whether the queue rejected work on purpose, timed out, or admitted a request that later failed. Each case leads to a different fix: a bounded rejection may be healthy load shedding, while a partial reservation needs transaction or compensation work. Write the distinction down before you compare runs.