Load Testing

An e-commerce platform handled 500 concurrent users comfortably during normal operations. On Black Friday, traffic spiked to 10,000 concurrent users. The database connection pool (max 20 connections) exhausted in 90 seconds. The application server ran out of memory at 2 minutes because each request handler allocated 50MB for image processing and nobody had tested what happened when 500 of them ran simultaneously. By minute 3, the entire platform was down. They lost an estimated $2 million in sales before restoring service 4 hours later.

Load testing would have revealed every one of these limits weeks before Black Friday. By simulating 10,000 concurrent users in a staging environment, the team would have discovered the connection pool limit at 500 users, the memory pressure at 2,000 users, and the cache miss storm at 5,000 users. All fixable with time to spare.

Amazon Web Services reports that 70% of their customers who experienced a major outage during a sales event had never load-tested at their expected peak traffic level. The other 30% had load-tested and fixed the bottlenecks before they hit production.

People use "load testing" as a catch-all, but there are four distinct types, each answering a different question.

A load test with 10,000 concurrent users for 30 minutes might pass perfectly. A soak test with the same 10,000 users for 12 hours might reveal a memory leak that adds 10MB per hour, eventually crashing the container. Both tests are necessary.