Load testing an application in isolation answers a narrower question than most teams think it does. The system that matters under real load is the application plus everything it calls, and the weakest of those is rarely the part you wrote.
What the first load test told us
Our own service handled several times expected peak traffic cleanly — sensible response times, no errors, resource usage well within limits. On paper, done. In practice, we had tested the part we controlled and left the part we did not entirely out of the picture.
What we had not tested
A payment provider's API, called synchronously during checkout, had a documented rate limit we had read and mentally filed as "generous enough". Under a simulated load closer to the client's actual peak — a product launch, not an average day — that limit was reachable well before our own infrastructure noticed any strain at all.
What we changed after finding it
- Load tests now simulate every external dependency at the rate limits and latencies it actually has, not at the generous, unthrottled speed a test double defaults to.
- Every synchronous external call in a critical path gets a defined behaviour for when the dependency is slow or throttled, decided in advance rather than discovered live — queue it, degrade gracefully, or fail loudly, chosen deliberately per call rather than left to whatever the default client behaviour happens to be.
- We ask every third-party provider for their actual, current limits in writing before launch, because published documentation has been wrong or outdated often enough that we no longer treat it as sufficient on its own.
A load test that only exercises code you wrote has tested the one part of the system least likely to be the actual bottleneck on launch day.
Fixing it for the client
We moved the payment call off the synchronous checkout path into a queued, retried flow with the user seeing an immediate confirmation and the actual charge confirmed shortly after — a bigger change than the client expected from what started as a load-testing exercise, but the only fix that removed the dependency's limit from being able to take down checkout.
The broader habit
Every load test we run now starts with a map of every external call in the path being tested, and a stated assumption about that call's behaviour under stress, checked against the provider directly rather than against the confidence of whoever integrated it originally.