How should we load-test our website before a major marketing launch?

Load testing is only part of the preparation. Aggressive caching, a CDN, rate limits, a waiting room, load balancing, and prioritizing important paths such as checkout can provide useful protection during a spike. Separate services that need independent scaling where practical, and make sure monitoring and alerts are already working.

Don’t choose an arbitrary multiplier like ten times normal traffic without understanding the campaign shape. Use the projected arrival rate, add an agreed safety margin, and test beyond that only within a controlled limit so the exercise remains safe.

Do the test in a production-like environment and document any differences. If you test against production, get explicit approval, schedule someone to monitor it, set stop conditions, use test accounts, and prevent real emails, payments, or orders. Don’t send load to external services unless you have permission.

The test should also verify that you can respond when things go wrong. Confirm that adding application instances, database capacity, queues, or other resources actually works and can be done quickly. It’s much better to discover a scaling or deployment problem during rehearsal than while the campaign is live.

Use a dedicated load-testing tool such as k6, JMeter, Locust, or Gatling. Model the actual customer journey instead of repeatedly requesting one URL: landing page, browsing, search, signup, checkout, and so on. Use realistic session data and enough variety to avoid making the test look easier than production.

Test your historical peak as a baseline, then the expected campaign load, followed by a reasonable amount of extra headroom. Ask the marketing team how many visitors are expected and how quickly they will arrive, since a concentrated email launch behaves very differently from traffic spread across several hours. An arrival-rate test is often more useful than simply starting a fixed number of virtual users, because slow responses can otherwise reduce the request rate and hide overload.

Define the pass criteria before testing. Track successful transactions, error rates, latency percentiles, throughput, database connections, slow queries, CPU and memory saturation, queue lengths, and autoscaling behavior. Also test the ramp-up, the sustained peak, and the recovery period afterward. The system should return to normal and drain its queues without manual restarts.

Run a small script-validation test first, then increase the load gradually while watching where performance starts to degrade. Make sure the load generators themselves can produce the requested traffic; otherwise you may mistake a test bottleneck for an application bottleneck.