What Breaks When Your Launch Actually Succeeds

A system that has run comfortably for a year can fail in the first four minutes of a campaign. Not because it was badly built, but because it has never been asked this particular question before.

These are the five answers it usually gets wrong, roughly in the order they show up.

1. The query nobody indexed

One database lookup, running on every page load, scanning the whole table. At normal traffic it costs milliseconds nobody notices. At a spike it becomes the queue everything else waits behind.

This is the most common single cause of launch-day outages, and usually the cheapest to fix once you know which query it is.

2. State living in one server's memory

Sessions, carts or in-progress forms held on the machine that served the first request. Adding servers then makes things worse, not better: half your users get routed to a server that has never heard of them.

3. The third party that rate-limits you

Your payment gateway, SMS provider or maps API has limits, and a spike is exactly when you hit them. Worse, the failure is often silent — the request just does not come back, and your system waits.

What to do about it

Know the limit before the date, queue requests rather than firing all of them, and decide in advance what the user sees when the third party says no. A clear message beats a spinner that never resolves.

4. Auto-scaling that arrives late

Auto-scaling reacts to load, and starting a new instance takes minutes. A campaign spike is over in less time than that. By the time the extra capacity is ready, the damage is done and the traffic is gone.

For a known start time, pre-warm capacity instead of scaling reactively. Reactive scaling is for sustained growth, not for spikes.

5. The queue that was fine per minute

Background work sized for ten jobs a minute does not survive ten a second. The site stays up, which makes this one easy to miss, but confirmation emails arrive four hours late and orders sit unprocessed.

How to find yours before your customers do

1. Copy production, including a realistic amount of data — testing against an empty database proves nothing
2. Load test at the number you expect, then at double it
3. Fix the first thing that breaks, then run the test again — the second bottleneck is always hiding behind the first
4. Repeat until the ceiling is comfortably above your expected peak
5. Write down who is watching on the day and what triggers a rollback

Expect three rounds. Expect the first bottleneck to be something nobody predicted. That is the normal outcome of doing this properly, not a sign anything was built badly.

If your launch is next week

There is still a useful version of this: find the single worst bottleneck, put a queue in front of the entry point, and reduce scope where you can. What nobody can honestly do in a week is guarantee the outcome.

How we run this is on the high-traffic campaign platform page, and what it looked like on a real campaign is in the case study.