A rush of traffic usually arrives attached to good news: a mention in the press, a thread that takes off, an ad that works better than expected. The difficulty is that the moment arrives unannounced, with no time to prepare.
The goal here is not a bigger server. It is arranging things so that the same server serves far more people.
What gives way first
A server can only handle so many requests at once. Past that point requests queue, and once the queue is long enough, later arrivals time out before earlier ones finish — which is why the failure is not gradual. Everything is fine, and then everything fails at once.
The key fact is that almost everyone is looking at the same screen. People arriving from one mention open one or two pages between them. Serving a copy made once, instead of rebuilding it for each arrival, changes how many people the same machine can carry.
Preparation 1 — have the page cache on already
The page cache from the previous part is decisive here, and it must be on and verified in normal times rather than switched on in the middle of the rush. Enabling it under pressure is how you end up with the wrong screen frozen in place on top of everything else.
Verifying it is easy: open a page twice while logged out (a private window works), and see whether the second load is noticeably faster. Many servers also mark cache hits in the response headers.
Preparation 2 — find your heavy screens
Every site has a handful of screens that cannot be cached: form submissions, on-site search, logged-in areas. Under load, those few are what actually tie up the server.
The countermeasures are undramatic. If you never use on-site search, turn it off; put anti-automation on the contact form. That alone removes a good share of the pressure, because automated traffic really does single out precisely those expensive screens.
Preparation 3 — images, and being told
Under a rush, the largest consumer of bandwidth is images. Resizing just the few large ones on your first screen changes how the site feels when it is busy.
Then confirm you are in a state where you get told when the site goes down. The last piece of preparation is finding out quickly — which is the next part.
Articles on load and cache configuration live in the performance archive, and if you would like the setup tidied before the rush arrives, our optimization program covers caching layers and server configuration together.
Next part
Next: detection. How to stop learning that your site is down from a customer’s message.