An API endpoint that is correctly authenticated, correctly authorized, and free of every injection and mass-assignment bug covered so far can still be brought down by a caller doing absolutely nothing malicious in the traditional sense — simply calling it far more often, or with far larger payloads, or with far more expensive parameters, than the backend was ever sized to handle. A single legitimate-looking request for a report spanning ten years of data, or a search query with a pattern that happens to be pathologically slow to evaluate, or a client retrying a slow endpoint in a tight loop because its own timeout is misconfigured, can each individually exhaust a resource — CPU, memory, database connections, disk — that every other caller on the same backend also depends on.
Rate limiting, quotas, and resource-exhaustion defences are the controls that keep one caller's usage, however it arose, from degrading service for every other caller — and unlike most of this course, the threat model here does not require an adversary at all, only an absence of an upper bound. A backend with no request-size limit, no pagination cap, no per-caller request rate, and no timeout on expensive operations is exposed to exactly the same outcome whether the trigger was a genuine traffic spike, a buggy retry loop in a partner's integration, or a deliberate attack — which is precisely why these controls belong in the same category as authentication and injection defence: an API without them is not fully specified, because it never actually defined what it does under load it was not designed for.
Analogy🏏Cricket
🏏 Think of it like cricket: A stadium's turnstiles are engineered to admit a known, tested maximum flow of spectators per minute, and every part of the venue downstream of the gates — the concourse width, the number of food stalls, the capacity of the stands themselves — was sized around that admission rate holding, not around however many people happen to show up. A ground that removed the turnstile's pacing entirely, letting every spectator with a valid ticket walk through simultaneously the moment the gates opened, would not be defeated by anyone doing anything wrong — every one of those spectators holds a genuine, valid ticket — the ground would simply be overwhelmed by an arrival rate nobody engineered the concourse to absorb, causing crushes and delays that have nothing to do with ticket fraud and everything to do with a missing pacing mechanism. This is exactly why every major venue enforces a controlled admission rate regardless of how legitimate every individual ticket holder is, because the venue's actual capacity was always a statement about flow over time, not simply about how many valid tickets exist. Just as a stadium's downstream capacity depends on the turnstile pacing admission, not on ticket validity alone, an API backend's capacity depends on a rate limit pacing requests, not on request legitimacy alone. Just as a crush at the gates can happen with zero fraudulent tickets involved, resource exhaustion can happen with zero malicious requests involved — sheer unpaced volume is sufficient on its own. The insight is that a system's real capacity is a rate, not a headcount, and any entry point without a mechanism to enforce that rate has left its actual capacity undefined regardless of how well-behaved any individual caller is.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.