What Is Rate Limiting?

Quick answer
Rate limiting caps how many requests a client can make in a time window.
It protects against abuse, brute force, and accidental overload of your API.
Common strategies include fixed windows, sliding windows, and token buckets, each with different trade-offs.

What is rate limiting?

Rate limiting is the practice of restricting how many requests a client — a user, an API key, an IP address — can make within a period. When a client exceeds the limit, the server rejects further requests (usually with HTTP 429 Too Many Requests) until the window resets. It’s a fundamental control for any public API.

Why it matters

Without limits, one misbehaving or malicious client can consume all your resources: a scraper hammering your endpoints, a brute-force attack guessing logins, or simply a buggy integration looping on retries. Rate limiting keeps one client from degrading the service for everyone else and bounds your infrastructure costs.

Common strategies

Fixed window — count requests in a fixed interval (e.g., 100 per minute); simple, but allows bursts at the boundary.
Sliding window — weight requests by their recency for a smoother limit.
Token bucket — a bucket refills tokens over time; each request spends one, allowing short bursts while bounding the average.
Leaky bucket — requests are processed at a steady rate, smoothing out bursts.

How to respond

Return 429 Too Many Requests with a Retry-After header telling the client when to try again, and document limits clearly. Graceful handling — the client backs off — is part of the contract, not just the server’s defense.

Where this bites vibecoders
AI assistants rarely add rate limiting unless asked, and “add auth” is often treated as the whole API-protection story. But authentication tells you who is calling; rate limiting tells you how much they can call. A public endpoint with no limit is a small mistake away from a bill or an outage — add a limit before you expose anything.

Where AI coding assistants get this wrong

Building public endpoints with no rate limiting at all.
Limiting by IP only, which breaks when many users share an IP.
Returning 500s instead of the proper 429 with Retry-After.
Setting limits that are either uselessly high or absurdly low.

Checklist

Identify which endpoints are public or expensive.
Choose a strategy that matches the workload (token bucket is a good default).
Key limits on identity (user/API key), not just IP.
Return 429 with Retry-After on exceeded limits.
Document the limits and log when clients hit them.

FAQ

What is a 429 response?

HTTP 429 Too Many Requests means the client has exceeded the rate limit. The response should include a Retry-After header so the client knows when it can try again. It’s the standard, machine-readable way to say “slow down.”

Is rate limiting the same as throttling?

The terms overlap, but throttling usually means slowing a client down (delaying or degrading service), while rate limiting means rejecting requests past a hard cap. Both aim to control request volume; the mechanism differs.

Why key on identity rather than IP?

Many users can share one IP (a corporate network or NAT), and one attacker can rotate IPs. Keying on the authenticated user or API key is more accurate, with IP as a secondary signal. See How to Add Rate Limiting to an API.