Load Testing for Traffic Spikes: When 200,000 Users Arrive in the Same Minute

Most systems fail politely under steady growth. Spikes work differently. A spike gives the team no ramp and no quiet hour to scale into. Here is why scheduled events keep breaking well-tested software, and what a spike test has to do that an ordinary load test skips.

The spike has a calendar

Surprise traffic is rare. The big spikes sit on a calendar months ahead: a ticket presale, a national final, a product launch. Every team knows the date. They still get flattened, because the date says nothing about how fast the crowd arrives.

Some of these dates synchronise a whole country. The first Tuesday in November empties offices across Australia and pulls every race-related service into its annual peak within minutes. The same evening lifts traffic on ranking pages, https://tribuna.com/en/casino/ratings/australia-casinos/ among them, because readers compare operators shortly before the event instead of a week earlier. Systems that looked independent hit maximum load in the same second.

Ticketmaster learned the arithmetic in November 2022. The Eras Tour presale generated 3.5 billion system requests in a single day, about four times the company’s previous peak, and the site buckled inside an hour. Four times. Not four percent. A capacity plan built on last year’s record missed by a margin no autoscaler absorbs quietly.

Ceilings keep climbing, and 2026 handed the industry three fresh reference points.

• March, the T20 World Cup final: the ICC put peak digital concurrency on the Indian stream at 72.5 million, though published numbers shift with the match and the broadcaster counted.
• Peacock and Telemundo logged around 13 million concurrent viewers in the United States for one knockout window.
• Over 117 Tbps ran through Amazon CloudFront during the July football final, the largest live peak the provider reports handling.

What a standard load test quietly skips

Performance suites usually measure a steady state: a fixed number of virtual users, held for an hour, response times drifting upward. That has value. It also answers a question nobody asked, since real crowds refuse to arrive at a constant rate.

1. Ramp speed changes everything. Climbing from 500 users to 200,000 in sixty seconds behaves nothing like reaching the same number across an hour.
2. Autoscalers lag. Provisioning fresh capacity takes minutes, a spike takes seconds, and the gap between the two is where users sit refreshing.
3. Caches start cold after every deploy, so the first few thousand requests go straight to the database that everyone assumed was protected.
4. Then there is the queue that never drains. Requests pile up faster than workers clear them, timeouts trigger retries, and retries feed the pile.

Point four causes more outages than raw capacity does. Sound familiar?

Designing a spike test that tells the truth

Build the test around the event, not a typical Tuesday. Pick the minute the marketing team has promised something, then model the shape of that minute rather than its total.

• Compress the ramp until it hurts. Full expected load in under two minutes is a reasonable starting cruelty.
• Test the recovery, not only the peak. Queues, retries and half-finished sessions keep moving through the stack long after traffic falls.
• Give bots a seat at the table. Ticketmaster opened that presale for about 1.5 million invited fans, and roughly 14 million entities hit the site. Model the scrapers.
• Run one test against production-scale data. A database holding 400 rows answers instantly and teaches nothing.
• Measure error rates per endpoint. An overall 2 percent failure rate can hide a checkout flow failing 60 percent of the time.

The morning the graph went the wrong way

Slack walked into this on 4 January 2021, the first working day of the year. Its traffic falls over the holidays and returns as a wall on the Monday everyone logs back in, with cold client caches pulling down more data than usual. Around 6 AM Pacific, one of its AWS transit gateways stopped keeping up and started dropping packets.

The next part deserves reading twice. Packet loss left servers waiting on the network, so their CPU usage dropped. The web tier scaled on CPU. Reading those low numbers as calm weather, the autoscaler began removing capacity during the busiest morning of the year. Slack published the sequence afterwards, and that postmortem still repays an hour.

A fixed-user-count test never surfaces that. Metrics picked in calm conditions can invert under saturation, and only a test that saturates something shows it.

Nobody needs to survive a World Cup final. Everyone needs to know what their own stack does when the ramp turns vertical, the cache is empty and the retries start stacking. Test that one minute properly and the rest of the year looks after itself.