Stress Test
Driving load beyond expected capacity to observe how the system behaves at and past its breaking point.
Load testing asks whether the system meets its target. Stress testing asks what happens when it does not — and that behaviour is a design property that should be chosen rather than discovered during an incident.
The questions it answers: where is the breaking point (which resource saturates first — usually not CPU); how does it break (graceful rejection with fast errors, or collapse with timeouts and cascading failure); does it recover when load returns to normal, or does a retry backlog keep it down; and what fails first, which is frequently a component nobody expected.
Desirable behaviour beyond capacity: fast rejection rather than slow failure — a 429 or 503 in milliseconds lets clients retry elsewhere or degrade, while a request that times out after 30 seconds holds resources and provokes a retry. Load shedding by priority, so partial capacity serves the most important traffic. Recovery without intervention once load subsides.
Two specific findings this test produces reliably: retry storms, where retries at several layers multiply and prevent recovery; and health checks failing under load, causing instances to be removed and concentrating load on the survivors.