advanced 3 min answer

Ticketmaster's own November 2022 statement on the Eras Tour onsale says the site drew about 3.5 billion system requests - roughly four times its previous peak - and that for the first time in 400 Verified Fan onsales the bots targeted its Verified Fan access-code servers. An interviewer says: "Design the waiting room for an onsale like that. How much of it runs at the edge?" Walk me through how you would scope and answer that.

ticketmasterqueueingadmission-controledgebot-traffic
Show the full answer Hide the answer

What the interviewer is testing

Whether you split a flow by what must be globally correct rather than by what feels latency-sensitive. The edge is excellent at absorbing connections and verifying things; it is structurally bad at owning a global count. A candidate who says "put the queue in edge key-value storage" has not noticed that a queue position is a global sequence and the edge has 300 independent copies of everything.

The second thing being tested is whether you can name the component that carries the correctness, because that is the component an attacker finds. In the reported account, the bots went for the access-code servers, not for the seat map.

The clarifying questions that change the answer

  • How much inventory? 2,000 seats or 200,000. With 2,000, admission is almost entirely about fairness and a pre-sale lottery beats a queue outright.
  • Fair-random or first-come? A lottery can be computed offline; first-come forces a global ordering.
  • Does the access code admit you to the queue or to a purchase? This decides whether the code check is on the hot path at all.
  • What duplicate-admission rate is acceptable? If admitting 4,100 people against 4,000 slots is fine, much more can be approximate. If it must be exact, a central mint is unavoidable.
  • Is a seat hold reversible, and for how long? Hold duration sets the admission rate more directly than any capacity number.

A strong answer's arc

The edge verifies. The centre mints.

At the edge: TLS and connection absorption, the static waiting-room page and its polling asset, per-IP and per-ASN rate limits, bot signals, and verification of a signed admission token - a public-key signature check needs no shared state, so it is correct in 300 places at once.

At the centre: the admission token mint, which is a counter releasing tokens at the rate the purchase path can absorb; the access-code to identity binding; the seat hold; payment. These are one-writer, exactly-once concerns.

The move that makes it work is pre-computation. Bind the entitlement to the identity before the onsale opens and hand the client a signed, expiring entry ticket. The hot path then verifies a signature instead of reading a database, which is what removes the access-code service from the attack surface rather than trying to scale it against 4x traffic.

The arithmetic worth saying aloud: a limit enforced per location is not a limit. 100 requests per minute per user applied independently across 40 locations permits 4,000. Any budget that must be global is minted centrally and spent at the edge as pre-signed tokens.

Common weak answers

  • "Use edge rate limiting for fairness." Approximate limits are fine for abuse control and wrong for entitlement. The per-location multiplication above is the reason.
  • "Scale the access-code service horizontally." It was 4x traffic and a targeted attack; the structural fix is to take it off the hot path, not to buy 4x of it.
  • "Autoscale the purchase path." Inventory is fixed. Admitting faster does not sell more seats; it converts a queue into contention on the same rows.
  • "Keep queue position in edge storage." Replication lag makes positions non-monotonic, and users compare screenshots.

What a strong answer adds

Say what you tell the business: the queue's release rate is a product decision about fairness versus throughput, and the honest framing is "we can admit N per minute; anyone beyond that waits, and the wait is visible". Then name where copying this is a mistake. For a 500-ticket show, the whole machine is over-built: a registration window that closes, a lottery, and emailed purchase links move the load off the critical second entirely, at the cost of the live-sale experience the business may actually be selling.