Handling Peak Traffic: Becoming Black Friday-Proof

During Black Friday 2024, AI chatbots caused a 1,800 percent increase in traffic to retail websites. At the same time, Cyber Monday generated 13.3 billion dollars in online revenue in a single day. The winners were the webshops that could handle this. The losers had an offline website at the moment it mattered.

Peak traffic is the biggest technical risk of the year for many e-commerce businesses. Not because the technology cannot handle it, but because the preparation is missing. This article is about that preparation: what you need to arrange, test, and monitor before, during, and after a peak moment.

Why webshops crash during peak traffic

Most crashes during Black Friday or other peak moments have the same cause: the infrastructure is built for average traffic, not for the peak. That peak can be 5 to 20 times higher than a normal day.

Common failure patterns:

• Database overload: at high concurrency, database connections fill up. Queries that normally take 50 ms suddenly take 2 seconds. The rest of the chain grinds to a halt.
• PHP worker exhaustion: every active webshop request occupies a PHP worker. When all workers are full, new visitors wait in the queue or get an error message immediately.
• Memory exhaustion: with high concurrent usage, memory consumption per server grows. Without a limit, this takes down the server. With a limit that is too strict, processes get killed.
• Third-party bottlenecks: payment providers, tracking scripts, chat widgets. If one external service is slow or fails, it blocks the page load for the entire shop.
• Session storm: tens of thousands of new sessions are created simultaneously. If sessions are stored in files instead of Redis, the I/O queue fills up.

Getting the basics right: what needs to be in place before peak season

Before you think about auto-scaling and load testing, there are basic measures that always need to be in place:

Redis for sessions and object cache. File-based session storage and direct database queries on every request are the two most impactful bottlenecks. Both are solved with Redis. This is not an optimization, it is a requirement.

Full-page caching for categories and product pages. During peak moments, you want as few requests as possible to reach the PHP stack. Product pages do not change with every request. Cache them. A well-configured Varnish setup can absorb 90 percent or more of page traffic before the webserver.

Database connection pooling. Tools like PgBouncer (PostgreSQL) or ProxySQL (MySQL) prevent hundreds of concurrent application processes from each opening their own database connection. A pooled system efficiently reuses existing connections.

Images optimized and served externally. Large images served directly from the webserver are a brake on performance and bandwidth. Use WebP format, compress on upload, and serve via a CDN.

Load testing: testing before it is too late

A load test simulates high numbers of concurrent visitors to discover where the infrastructure fails first. You do this well before the peak moment, so you can fix problems.

The most commonly used tools:

• k6: modern open-source load testing tool with JavaScript scripts. Readable output, integrates well with CI/CD pipelines.
• Locust: Python-based, flexible. Suitable for complex scenarios with logging in, searching, and purchasing.
• Apache JMeter: the traditional choice, extensive but more complex to configure.

Always test with realistic scenarios. A load test that only queries the homepage is not representative. Simulate a mix of: product pages, category overviews, search actions, shopping cart interactions, and checkouts. Use a mix of logged-in and non-logged-in users.

Test at a minimum of three times your expected peak level. If you expect 5,000 concurrent visitors on Black Friday, test at 15,000. Peaks are rarely exactly what you plan.

Horizontal scaling for peak absorption

If the load test shows that one server cannot handle it, there are two options: vertical scaling (larger server) or horizontal scaling (more servers). For peak absorption, horizontal scaling is more flexible: you add servers during the peak and remove them afterward to save costs.

In cloud environments, you can configure auto-scaling based on CPU usage or incoming requests. Note: starting a new server takes 1 to 3 minutes. During a sudden peak (viral effect, opening time of a sale), that is too late. Make sure you have the capacity added before the peak.

A hybrid approach works best: a fixed base capacity that can handle your normal traffic, supplemented with reserved cloud capacity that you activate manually or automatically for peaks.

Monitoring during the peak

During a peak moment, you want real-time visibility into what is happening. Not after visitors complain or the site is down. Set up dashboards and alerts for:

• Response times per endpoint (dashboard and product pages are the most critical)
• Server CPU and memory usage
• Number of active PHP workers versus available capacity
• Error rate (HTTP 500s, timeouts)
• Redis and database connections in use
• CDN cache hit percentage (a low percentage means too much traffic reaches the origin server)

Set thresholds that warn you before things go wrong. If CPU goes above 70 percent, that is a signal to take action. Waiting until 95 percent is too late.

The human factor

Technology can handle quite a lot. What is often missing is a clear protocol for when something does go wrong. Establish in advance:

• Who has access to the servers and can intervene immediately?
• What is the decision point to add extra capacity?
• How do you communicate with customers if the site is slow or unreachable?
• What is the procedure if a deployment needs to be rolled back?

During a peak, there is no time to figure this out. You arrange this in the weeks before.

Conclusion

Being Black Friday-proof is not a technical wonder. It is a combination of basic hygiene (caching, Redis, CDN), proactive capacity planning, load testing, and good monitoring. Most webshops that crash during peak traffic could have prevented it with thorough preparation of four to six weeks.

Start early. Test hard. Monitor everything. And make sure someone is available on the day itself.

Ready for peak traffic? Check out our e-commerce hosting or high-traffic solutions.