Rate Limiting - Controlling API and Web Traffic

About 2 min read

Rate limiting is a mechanism that sets an upper limit on the number of requests accepted within a given time window, protecting a service from overload and abuse. It is widely adopted to mitigate DDoS attacks, curb brute-force attacks, and ensure fair use of APIs. As of 2025, with the expansion of the API economy, rate limiting has become established as a fundamental requirement of API security.

Who Actually Slows Down When There Are No Limits

In an API without rate limits, processing capacity is effectively allocated on a first-come, first-served basis. If a single client keeps sending a large volume of requests, that client monopolizes shared resources such as connection slots, CPU time, and database connections, and the ones left waiting are unrelated users. The symptom that surfaces as an incident is a general slowness in responses, while the specific client causing it does not appear on the surface. This state does not require malice either: a client with a naive retry implementation, or a batch job performing an initial bulk synchronization, produces the same result. Rate limiting is therefore not only a means of blocking attacks but also a mechanism that cuts the path by which one user's behavior spills over into other users' experience. When the upper limit is stated explicitly, the client that exceeds it is also told that it has reached a limit, so the situation does not have to be handled as an unexplained slowdown.

Rate Limiting Flow

Key Algorithms

The fixed-window approach measures requests within a fixed time frame, such as "up to 100 requests per minute." It is simple to implement, but suffers from the problem of bursts of requests concentrating at window boundaries. The sliding-window approach measures over the most recent time frame, mitigating the burst problem. The token-bucket approach is a model in which tokens are replenished at a constant rate and each request consumes a token, allowing short bursts while limiting the average rate.

Implementation Scenarios

On a login endpoint, login attempts from the same IP address are limited to "up to 10 times in 5 minutes" to curb credential stuffing. For APIs, tiered limits are set, such as "1,000 requests per hour" for authenticated users and "100 requests per hour" for unauthenticated users. When the limit is exceeded, an HTTP 429 (Too Many Requests) response is returned along with a Retry-After header to tell the client an appropriate wait time. Combining API key management with rate limiting effectively prevents the abuse of APIs.

Design Considerations

Rate limit thresholds must be set by analyzing the usage patterns of legitimate users. If the threshold is too low, it harms the experience of legitimate users; if it is too high, it fails to prevent attacks. In distributed environments, counters are managed in a shared store such as Redis to apply consistent limits across multiple servers. Combining strong random passwords with rate limiting can significantly improve the security of login pages.