When a platform falls over at its busiest hour, the first instinct is to add web servers. It is almost never the web servers.
Web servers are stateless. They scale, and autoscaling handles them well. The things that break sit behind them, and they share one trait: a hard ceiling that does not move when traffic doubles. On an average day you never reach it. In the one hour that matters, you do.
Here are the five that go first, in roughly the order we see them go. The full argument, including why peak is not a bigger version of normal, is in Why platforms fail at peak but not on average.
1. Database connection pools
The ceiling: max connections on the database. Fixed. Does not scale with the web tier.
Every web server holds a handful of open connections. Add web servers and you multiply demand on a database whose connection limit has not changed. This is how autoscaling makes peak worse: the web tier scales up in minutes, the database does not scale at all, and the new servers arrive just in time to exhaust the pool.
Before the window: put a pooler such as PgBouncer or ProxySQL between the application and the database, and size the pool from what the database can take, not from how many app servers happen to be running.
2. Queues that fill faster than they drain
The ceiling: worker throughput. Once arrivals exceed it, the backlog grows without bound.
A queue protects you right up to the moment jobs arrive faster than workers can process them. After that the backlog itself becomes the failure: memory fills, latency climbs, and jobs are processed long after anyone needed them. Retries make it worse, because every retry is a new arrival.
Before the window: bound the queue and reject when it is full. Rejecting a request in five milliseconds is kinder than accepting it and failing after thirty seconds.
3. Third-party rate limits
The ceiling: somebody else's per-minute quota, sized for your average month.
Payments, email, maps, address lookup, tax data. Each provider caps calls per minute, and each cap was fine when you signed up. At peak you hit it, and the errors come back looking like your own. Nobody thinks to check the vendor dashboard while the site is down.
Before the window: write down every limit, meter your own calls against it, push anything non-urgent through a queue, and build the degraded path now: send the email later, show the cached rate, never block checkout on a lookup.
4. Full-table scans on large tables
The ceiling: one slow query, multiplied by concurrency.
A query that scans a large table runs fine at ten concurrent users. At five hundred it holds locks, starves the connection pool from item one, and takes everything else down with it. The usual culprit is a report or dashboard someone opens against the live database at the exact moment load is highest.
Before the window: precompute the expensive numbers ahead of time, index for the queries peak actually runs, and move reporting off the primary.
5. Cache expiry at the wrong moment
The ceiling: the database behind the cache, which was sized on the assumption the cache would hold.
A cache hides the database until the moment a key expires. If a popular key expires at peak, or thousands of keys expire together because they were set together, every request misses at once and lands on the database. The stampede looks like a database failure. It is a scheduling failure.
Before the window: add jitter to expiry times so keys do not expire in unison, serve stale data while revalidating, and warm the cache before the traffic arrives.
What they have in common
None of these show up in a load test that spreads peak volume across an hour. They show up when you replay the real shape of the traffic: the burst, the retries, the report somebody opens at the worst possible time. Test at peak shape, not peak volume, and put feature flags on anything non-essential so it can be switched off before the window opens rather than during it.
This is the discipline behind FreeTaxProtest, a platform handling 90,000+ homeowners per cycle with 100% uptime at peak. The traffic there is not spread across the year. It arrives in a window, and the system was built for the window.