25.1 Why limit?

The algorithms

At the club: Without a door policy, the room overflows: nobody can move, the bar runs dry, the fire marshal shuts the place down. One group of 50 could take every spot. And the club's costs (staff, drinks) are planned for a certain crowd.

In the system: A rate limit caps how many requests a client can make in a period. Reasons:

• Protect the service. A bug in one partner's code that calls GET /books in a tight loop shouldn't take the API down for everyone. Limits turn an overload into a clear "slow down" for one client.
• Fairness. One heavy client shouldn't use up capacity that others need.
• Cost control. Some calls are expensive: they hit the database, call a paid SMS gateway or run an AI model. Limits keep the bill predictable.
• Security. Slow down brute-force password guessing, OTP guessing, scraping and spam (25.7).
• Business plans. Free plan: 100 a minute. Paid plan: 1,000 a minute.

What a limit is defined by:

• Who: per API key, per user, per IP, per account, per endpoint, or a combination.
• How many, over what time: 100 per minute, 5 per 15 minutes.
• What happens when exceeded: reject with 429 (most common), delay (queue it), or degrade (serve cached results).

Rate limits are not a substitute for capacity planning (Chapter 6) or load shedding (Chapter 29). They protect against individual clients misbehaving; if all your normal users arrive at once, you need more capacity.

Memory code: "Limit the few so the room works for everyone."

---