load-testing
Load Testing
A load test that hammers a single endpoint with identical requests until it falls over answers a question nobody asked. Production traffic is a mix — read-heavy here, write-heavy there, some users idle, some hammering the API — and the interactions between those flows are exactly what break systems that look fine in isolation. A load test that doesn't resemble real traffic validates nothing real.
The goal is not to prove the system survives; it's to find the load level and failure mode where it doesn't, on purpose, before a real spike does it for you.
A load test that never fails the system hasn't found its limit — it's found its patience.
1. Model the traffic shape, not just the volume
Total requests per second is the least interesting number in a load test. What matters is the mix of operations, their relative frequency, and the pattern of arrival — bursty versus steady, diurnal versus flat. A test that sends uniform traffic when real traffic bursts at the top of every minute will miss the exact failure that burst causes.