What is rate limiting?
A server-side policy that caps how many requests a client can make in a given window, returning 429 Too Many Requests when the cap is exceeded.
Rate limiting protects services from overload, abuse, and runaway clients. The server tracks request counts per identifier (usually IP, API key, or user account) and rejects new requests once the count exceeds a configured threshold. Common algorithms include fixed window, sliding window, token bucket, and leaky bucket.
When you're building against an API, the limit shows up as 429 Too Many Requests plus a Retry-After header (or sometimes X-RateLimit-Remaining and X-RateLimit-Reset). Robust clients read those headers and apply exponential backoff with jitter; naive clients hammer the same endpoint and get themselves blocked harder.
When you're building a service, rate limiting is non-negotiable past a certain scale. The questions are which dimension you bucket on (IP, key, user, route), what algorithm you use, and where the counter lives (in-memory, Redis, edge). Most modern stacks settle on sliding-window-with-Redis at the application layer plus IP-based limits at the edge.
In the wild
- GitHub returning 5,000 requests/hour for authenticated REST clients
- Stripe applying a 100 req/sec live-mode limit, scaling on request
- A scraper backing off when it hits a 429 with
Retry-After: 60