Capacity meets demand
Your servers have finite capacity, and demand has no reason to respect it.
A rate limiter is the layer that enforces the difference. It caps what any single client can consume, so your total load stays inside what you provisioned and no one client can ruin the service for everybody else.
Expect the threats to be mundane far more often than malicious. Yes, it blunts brute-force logins and cheap flooding attacks.
The traffic that actually takes down real APIs is usually friendly fire. A customer's misconfigured integration retrying in a loop. A mobile release with a polling bug. A data science team backfilling through your production API at 400 requests a second.
Your limiter turns each of those from an incident into a stream of refusals and a support conversation.
Fairness, and the pricing page
Take fairness as the second job, as much a business function as a technical one. In a system serving many customers, capacity is shared, and without limits your noisiest tenant taxes everybody else.
Turn tiered limits into product structure. Free accounts get 100 requests an hour, the enterprise tier gets 100,000, and that limit becomes a line on your pricing page. Every serious API provider publishes their numbers, because a documented limit is a contract clients can build against.
Name the self-protective angle too: retry storms. When your service slows down, well-meaning clients time out and retry, which adds load, which slows it further, and a wobble becomes a collapse.
Shed that excess early and cheaply, before it reaches your application code, and you break the loop. Take that framing into design interviews: rate limiting is not a bouncer for bad actors, it is admission control keeping your system inside the envelope you built for it.
Worked example
At 02:10 on a Sunday, a client of Meera's shipping API deploys an integration with a broken retry loop: every failed call retries instantly, forever. Traffic from that one API key climbs from 2 requests per second to 3,800. Without limits, that load would have saturated the label-generation workers all customers share. Instead, the gateway's limiter holds the key at its documented 50 requests per second, and 3,750 requests per second get 429s that cost about 100 microseconds each, no database, no worker time. Every other customer's latency at p99, the slowest one request in a hundred, stays flat, and Meera finds out from a dashboard, not a pager. Monday morning, support sends the customer their own traffic graph; the customer fixes the loop and apologizes. Total incident cost: one email.