Peak Multiple

"We are provisioned to twice last year's peak" is the most common capacity statement in the industry, and it is three assumptions wearing one number: that the population which can generate load is the one you served last time, that it grows at a rate the multiple covers, and that the arrival curve has a similar shape.

The multiple hides all three, which is why it survives review. It is a good heuristic for organic traffic and a dangerous one for anything scheduled or scarce.

Why it matters

A peak multiple is an interpolation - it extrapolates from history within the regime that produced the history. The failures come from regime changes, and the most common regime change is publicity.

When an event is newsworthy, the set of clients that can send you a request is the internet, not your customer list. The ratio between those two has no ceiling you can derive from your own data, because your data only contains events that were not newsworthy enough to attract that traffic. So the multiple is calibrated on exactly the sample that excludes the case you are worried about.

A second mechanism: scarcity plus a published start time converts an access-control design into a thundering-herd design. Everyone who wants the scarce thing knows when to arrive, whether or not they hold permission, and the rational move for a determined buyer is to arrive early and retry.

Implementation patterns

• Produce two numbers, not one. The load you intend to serve (invited or expected users × sessions × requests per session) and the load that can arrive. The first sizes the fleet; the second has no ceiling and therefore becomes an admission-control requirement - the waiting room, the rate limiter, the shedding policy.
• Size the arrival rate as well as the total. A day's traffic delivered in sixty seconds is a different system from the same traffic over an hour, and autoscaling on a five-minute horizon loses that race whatever the target size.
• State the dominant assumption explicitly, then ask what you would do if it were 10× out. If the answer is "nothing survives", the design needs a queue, not more servers.
• Separate legitimate from illegitimate traffic in the model. Bot load is a security number and a capacity number at the same time, and it belongs in the estimate rather than in a separate document.
• Re-derive after every event, keeping the ratio of arriving clients to intended clients as the tracked quantity. That ratio, not the absolute peak, is what predicts the next one.

Industry example

Ticketmaster stated that its November 2022 Eras Tour verified-fan onsale drew 3.5 billion total system requests - four times its previous peak - after inviting 1.5 million fans from over 3.5 million pre-registrations, and attributed the excess to bot attacks and to people arriving without invite codes. The invited population was known precisely in advance; the arriving population was not bounded by it at all.

The general lesson is not about ticketing. Any flash sale, limited drop, exam-results release or registration deadline has the same structure: a published time, a scarce resource, and a population defined by the outside world.

Failure scenarios

• Sizing to a multiple of the invited population when the arriving population is unbounded.
• Peak-of-averages. A multiple applied to a daily or hourly average rather than to the instantaneous arrival rate, which understates the real peak by an order of magnitude.
• Missing the shape change. The total is right and it arrives in one minute instead of thirty.
• The database sized and the front door not. Requests that never reach the database still cost TLS termination, session creation and bot classification.
• Autoscaling as the plan. Scaling on a five-minute horizon against a sixty-second spike; the capacity arrives after the event.
• A multiple that grew by habit. 2× becomes 3× becomes 4× without anyone re-deriving what it is a multiple of, so the cost rises and the exposure does not change.

Trade-offs

The multiple is genuinely useful: it is cheap, it communicates in one number, and for organic growth it is about as accurate as anything more elaborate. Replacing it with a full arrival model costs days of work and produces a number with a wider error bar, which is harder to defend in a budget conversation even when it is more honest.

The cost of keeping it is concentrated in rare events, which is precisely when the cost is highest and when nobody has time to discover the assumption.

When not to use it

When demand is set by a contract or a known input volume, the multiple is fine and anything more is waste: an internal tool with 4,000 employees, a nightly batch whose input size is known a quarter ahead, a B2B API with negotiated rate limits.

Conversely, do not rely on it when the item is scarce and the start time is public. Those two facts, not the traffic volume, are the trigger for the harder estimate - and they are usually known weeks in advance, which makes this one of the rare capacity risks that is cheap to see coming.

Interview question

Q: You are sizing the launch of a limited-edition product drop. Marketing expects 200,000 interested buyers for 5,000 units, and the drop time will be announced a week ahead. Your platform's previous peak is 40,000 requests per second. What do you provision, and what do you build that is not capacity?

What a strong answer covers: that the interested-buyer figure bounds intent and not arrivals, so the estimate splits into served load and arriving load · the arrival-rate calculation rather than a total, since everyone arrives in the same few seconds · a waiting room or queue with a fair admission order as the primary mechanism, with capacity as secondary · retry behaviour on the client, because naive client retries multiply the arrival rate · what is shed first and what must never be shed · bot classification as a capacity concern · and the measurement to keep afterwards: arriving clients over intended clients, which is what sizes the next drop.

Quick check

Quiz: Why does a peak multiple fail specifically for scarce, scheduled sales? Because it assumes the load-generating population is the one you served before, and a published start time plus scarcity means the population is everyone who wants the item - a ratio with no ceiling derivable from your own history.

Flashcard: What does the second number in a two-number peak estimate size? — Not the fleet. It sizes admission control: the waiting room, the rate limiter and the shedding policy, because it has no ceiling.