Your capacity plan sizes the platform at twice last year's peak. Ticketmaster's November 2022 Eras Tour onsale took 3.5 billion system requests - four times its previous peak - after inviting 1.5 million verified fans. Which assumption inside a peak-multiple estimate fails first?

What a peak multiple really assumes

"Twice last year's peak" is not one estimate. It is three stacked assumptions: that the population which can generate load is the population you served last year, that the population grows at a rate the multiple covers, and that the shape of the arrival curve is similar. The multiple hides all three, which is why it survives review.

Ticketmaster stated that its 2022 Eras onsale reached 3.5 billion system requests, four times its previous peak, and attributed the excess to bots and to people without invite codes arriving anyway. 1.5 million fans were invited. The load did not come from the invited population, so no multiple of the invited population would have sized it.

Why the invited-population assumption fails first

The other three assumptions degrade gracefully. This one inverts. When an event is newsworthy, the set of clients that can send you a request is the internet, not your customer list — and the ratio between the two is unbounded in a way your historical data cannot show you, because your historical data only contains events that were not newsworthy enough to attract that traffic.

The mechanism is specific: an invite-only sale publishes a time. Everyone who wants the thing knows when to arrive, whether or not they hold a code, and the rational move for a determined buyer is to arrive early and retry. Scarcity plus a published start time converts an access-control design into a thundering-herd design.

Why the other options fail

• "Traffic grows smoothly." A real mistake, and it fails second, not first. Smooth growth is a fine model for organic traffic; it has never been a model for a scheduled scarce sale, and everyone sizing one knows that. Catching it does not save you here.
• "The database saturates before the front door." Often true and worth checking, but in this shape the front door — TLS termination, queueing, session creation, bot classification — meets the traffic first, and requests that never reach the database still cost you. Sizing the database to 4× would not have helped.
• "Autoscaling adds capacity faster than demand arrives." A genuine error people make, but subordinate: autoscaling on a five-minute horizon against a sixty-second arrival spike is a losing race whatever the target size. It tells you the shape is wrong, not that the population is wrong.

What to estimate instead

Estimate two numbers, not one. The load you intend to serve (invited buyers × sessions × requests per session) and the load that can arrive (a number with no ceiling, so it becomes an admission-control requirement rather than a capacity requirement). The first sizes the fleet. The second sizes the queue, the rate limiter and the shedding policy.

Then state the one assumption that dominates the error — here, the ratio of arriving clients to invited clients — and say what you would do if it were 10× your guess. If the answer is "nothing survives", the design needs a waiting room, not more servers.

When this is over-thinking it

For a sale with no scarcity, no published start time and no secondary market, the invited population really is the bound, and a 2× multiple on last year is a fine estimate that costs an afternoon. The assumption only becomes load-bearing when the item is scarce and the start time is public. Those two facts, not the traffic volume, are what should trigger the harder estimate.