The busiest hour of the year, and an error page
The sale email goes out. The influencer posts. The product gets mentioned on television. Within minutes the site slows to a crawl, then starts showing errors. The team refreshes the hosting dashboard, someone restarts the server, it comes back briefly and falls over again. By the time it recovers, the peak has passed.
The marketing worked. The site did not. And the same thing happened at the last big campaign.
Why sites fall over under load
A site under a sudden spike usually fails at one weakest point, and everything behind it queues up and times out.
| Bottleneck | What happens under load |
|---|---|
| Uncached pages | Every visitor makes the server build the page from scratch |
| Database | Slow queries that were tolerable become a queue that never clears |
| Fixed server size | One server with no way to add capacity when load rises |
| Sessions and carts | Stored in a way that stops extra servers being added |
| Third-party calls | A slow payment, stock or shipping API holds up every request |
| Heavy pages | Large images and scripts multiply the load on every visit |
The detail that catches people is that the home page is often fine, because it is cached. It is the category, search, basket and checkout pages, the ones that matter during a sale, that cannot be cached and fall over first.
What a crash at peak costs
Sales you would have made in the busiest hours. Advertising and campaign spend that sent people to an error page. Customers who tried, failed and bought elsewhere. And a team that dreads promotions, which leads to marketing being held back so the site survives.
How we prepare a site for peaks
- Load-test first. Using tools such as k6 or JMeter, we simulate realistic traffic on a staging copy, including browsing, searching and checking out, and watch where it breaks.
- Put a CDN in front. Services such as Cloudflare, Amazon CloudFront or Azure Front Door serve images, scripts and cacheable pages from the edge, so most requests never reach your server.
- Cache what can be cached, including pages for anonymous visitors and expensive query results, with sensible rules for refreshing them.
- Fix the slow queries and code paths the load test exposes, particularly on search, basket and checkout.
- Make the application able to scale out: sessions and carts in a shared store such as Redis, and servers or containers that can be added automatically when load rises, using autoscaling on AWS or Azure.
- Protect against slow third parties with timeouts, retries with limits, and queues for work that does not need to happen during the request.
- Plan for beyond capacity. A virtual waiting room or a lightweight holding page for extreme peaks is better than a crash for everyone.
- Run a checklist before known events: scale up in advance, freeze deployments and have named people watching the dashboards.
For platforms like Shopify, much of this is handled by the platform, and the bottlenecks move to apps, themes and integrations. We look at those instead.
When the next campaign lands
You know from testing roughly how much traffic the site can handle and where it will strain first. Most traffic is served from the CDN and cache. The servers scale out when load rises and back down afterwards. If demand exceeds everything, visitors see a queue rather than an error. And marketing can plan campaigns without asking whether the site will survive.
Recognise the pattern?
- Your site has slowed down or crashed during a sale, launch or campaign.
- The fix during an incident is restarting the server.
- Your site runs on a single server with no automatic scaling.
- You have never load-tested the site.
- Marketing holds back promotions because of worries about the site.