Black Friday load testing for online shops
A campaign takes months to prepare: discounts, emails, advertising, and stock. If traffic rises more sharply than the system can handle, the online store may begin responding slowly or failing precisely at the cart and payment steps. The problem then affects customers whom you brought to the website through a paid campaign.
A performance problem does not have to result in a complete outage. It may appear as gradual slowing or errors in only a portion of requests. Without technical metrics, it is then difficult to distinguish the effect of performance from other causes of a drop in conversion.
Common problem: an estimate without a load test is not enough
Normal traffic alone does not confirm how the system will behave during a campaign. Capacity is affected by the customer scenario, the amount and structure of data, external services, and the available infrastructure. Once a resource such as database connections, memory, or worker threads is exhausted, response times and the error rate can deteriorate more sharply.
You need to know that point before the campaign, not during it.
How to measure capacity
We design scenarios around important customer journeys, such as arriving on the website, finding a product, adding it to the cart, registering, and paying. A simple home-page test can be useful for a partial measurement, but it does not load the same parts of the system as the complete purchase process.
We then gradually increase the load and observe what happens:
Normal traffic (load). Can the system handle the expected traffic with response times that are acceptable to customers?
The limit (stress). At what load does the system stop meeting the agreed limits, and which resource is approaching its capacity at that time?
A sudden peak (spike). Traffic can rise in a short time after a newsletter is sent or an advertising campaign launches. The test verifies how the system handles the jump and whether it returns to its normal state afterwards.
Long-term stability (soak). Can the system maintain the agreed performance level during a prolonged load? The test duration is selected according to the risk and operational profile. The test may reveal memory leaks, unclosed connections, or storage that gradually fills up.
We evaluate response times with both the average and percentiles. The average alone can hide a small share of very slow requests; p95 and p99 show thresholds for 95% and 99% of measured response times. These values need to be interpreted together with the error rate, throughput, and the specific scenario.
What the test result gives you
The result is capacity measured for specific scenarios and agreed response-time and error-rate limits. The metrics can indicate a likely bottleneck, such as slow SQL queries, waits for a database connection, or a saturated infrastructure resource, and determine what needs further verification. Recommendations can be ranked by risk, expected benefit, and effort.
We compare the test metrics with the available application, database, and infrastructure metrics on one timeline. Timing relationships help form a hypothesis about the cause, which must be confirmed with additional data or a repeated test.
When to start
The required lead time depends on the size of the system, environment availability, and the difficulty of potential changes. For a larger campaign, it may be useful to start several weeks in advance so that there is time for the first measurement, changes, and a repeated test. One week before launch may allow only limited verification and mitigation of the greatest risks.
The same reasoning applies before launching a new product, a large advertising campaign, or a migration to different infrastructure.
Next step
Prepare typical customer journeys, an estimate of expected traffic, the campaign date, and the response-time and error-rate limits you consider acceptable. This information can be used to determine a realistic test scope and the required lead time.