Rate limiting
Also known as: API rate limiting, request rate limiting, rate limits, request throttling
Rate limiting is a technique that controls how many requests a person, app, or IP address can make to a service within a set time, such as 100 requests per minute.
Once the limit is reached, further requests are slowed or rejected until the window resets. It protects websites and APIs from being overwhelmed, stops brute-force login attempts, and keeps usage fair. While rate limiting is essential, limits that are too strict frustrate legitimate users.
Rate limiting, explained at three levels
At home
Rate limiting is like a bouncer letting only a certain number of people into a club each minute. It keeps things from getting dangerously crowded.
At work
Rate limits protect business websites and APIs from crashes and abuse.
At home
If you type a wrong password too many times and get locked out briefly, that's rate limiting protecting your account.
At work
Common approaches include fixed windows, sliding windows, and token buckets. Responses should include 429 status codes and headers telling clients when to retry.
At home
Apps that scrape or sync data too aggressively can get blocked. In my opinion, that's usually rate limiting doing its job, not a bug.
At work
Apply limits per user, API key, and IP, protect login and password reset endpoints especially, handle distributed attacks with edge protections, and design clients with backoff and retry logic.
Real-world examples
At home
Carlos got a 'too many attempts, try again later' message after mistyping his password. Rate limiting stopped anyone from guessing it quickly.
At work
Fatima runs a Halifax booking platform. Adding rate limits to its login page stopped a credential stuffing attack without affecting customers.
How it compares
| feature | Rate limiting | Bandwidth throttling |
|---|---|---|
| Purpose | Cap requests over time | Slow data speed |
| Measured in | Requests per period | Data per second |
| Common use | APIs, logins | Networks, ISPs |
| User sees | Errors or waits | Slower speeds |
Rate limiting caps requests. Throttling slows data.
For analysts
In API requirements, I'd specify rate limits and how clients should handle them. Partners building integrations need that information on day one.
History & origin
Network engineers developed traffic-shaping algorithms, such as the 'token bucket' and 'leaky bucket,' in the 1980s and 1990s to control data flow. As public web APIs grew in the 2000s, companies such as Twitter imposed strict rate limits on developers, sometimes controversially. The HTTP status code 429 'Too Many Requests' was standardized in 2012. Cloud providers and services such as Cloudflare made rate limiting easy to apply at the edge, and AI APIs from the 2020s set limits on requests and tokens per minute. In my view, rate limiting is one of the simplest, most effective defences any online service can add.