Rate limiting

Why it matters

It protects a system from both abuse, a brute-force login attempt or a scraping bot, and from accidental overload, a poorly written integration hammering an API far faster than intended. Without it, a single misbehaving client, malicious or not, can degrade or take down service for everyone else. It also protects cost, not just uptime: a metered third-party API called far more often than intended by a bug, rather than an attack, can generate a large, unexpected bill purely from unrestrained internal request volume. It also has to be tuned per endpoint rather than applied uniformly, since a login endpoint and a public read-only search endpoint have very different legitimate usage patterns.

What goes wrong when it's handled badly

A system with no rate limiting at all is trivially open to both abuse and accidental self-inflicted outages from a bug in a connected system. A rate limit set too aggressively in the other direction can throttle a legitimate integration that genuinely needs higher throughput, which is why limits are set deliberately per use case rather than applied as one blanket number. A concrete example is a password reset endpoint with no rate limit, letting an attacker attempt thousands of guesses against a single account in minutes, a straightforward brute-force attack that a simple limit of a handful of attempts per hour would have stopped outright. Returning a clear, machine-readable response when a limit is hit, rather than a generic error, lets a legitimate integration back off and retry correctly instead of failing unpredictably. Communicating limits clearly in API documentation is what lets a legitimate integration design around them instead of discovering them only by hitting a wall in production.