Rate Limiting

Rate limiting is a mechanism that controls how many requests a single client may send to a server, API, or service within a defined time window. Once the limit is exceeded, additional requests are rejected — usually with an HTTP 429 Too Many Requests response — or delayed. Rate limiting keeps a service available to everyone, shares resources fairly, and makes many forms of abuse harder, such as DDoS, brute force, credential stuffing, and scraping.

How does rate limiting work?

A rate limiter rests on three things. The first is a key that identifies the sender — an IP address, an API key, or a user or session identifier. The second is a limit, the maximum number of requests allowed. The third is a window, the time interval over which the limit applies (e.g. 100 requests per minute). For each key, the system counts requests in the current window and compares the count to the limit. Once the allowance runs out, further requests are blocked or queued until the window renews.

The choice of key matters. Limiting by IP alone is simple, but it fails in two cases. First, when many users share one address — this is how NAT, proxies, and CGNAT work, hiding many devices behind a single address. Second, when an attack comes from many addresses at once. Limiting by API key or user account is more precise, as long as the traffic is authenticated. In practice, several limits run at the same time — separate caps per IP, per user, and per endpoint.

What are the rate limiting algorithms?

How requests are counted affects three things: how accurate the limit is, how well it tolerates short traffic bursts, and how much memory it uses. The five most common approaches are:

• Fixed window — splits time into equal intervals (e.g. each clock minute) and counts requests in the current one. Simple and memory-cheap. Its weakness is the boundary problem: by clustering requests just before one window ends and just after the next begins, a client can pass double the limit in a short span.
• Sliding window log — stores the exact time of every request. On each new request it drops entries older than the window length and counts the rest. The most accurate and fair, but memory-hungry under heavy traffic.
• Sliding window counter — approximates the sliding window. It takes the counters of the current and previous windows and weights them by how much time has passed. A good compromise: it nearly removes the boundary problem at moderate memory cost.
• Token bucket — a bucket fills with tokens at a fixed rate, up to a set capacity. Each request spends one token. A client that was idle for a while builds up a reserve of tokens and can then catch up with a short burst, while keeping the average rate. A common default for public APIs.
• Leaky bucket — requests enter a queue that drains at a constant rate. When the queue overflows, the excess is dropped. It forces a smooth, steady pace with no room for bursts — useful for shaping outbound traffic.

Where is rate limiting enforced?

Rate limiting runs at several infrastructure layers, often at once:

• Network edge / CDN — stops excess or malicious traffic as close to the source as possible, before it reaches the origin.
• WAF (Web Application Firewall) — combines limits with rules for specific paths (e.g. tight limits on /login and search).
• API gateway — enforces policies across all API traffic, such as limits per API key, per subscription tier, or per endpoint.
• Reverse proxy / load balancer — for example, rate limit modules in servers such as Nginx or HAProxy.
• Application layer — the most granular control, based on business logic (e.g. limiting by request cost, not just count).

In distributed environments, counters must be shared across instances (e.g. in Redis). This brings a trade-off. Strong consistency gives an accurate limit, but at the cost of latency. Eventual consistency is faster, but allows brief overages.

How does rate limiting protect against attacks?

From a security standpoint, rate limiting slows down and hinders an attack, but it is not full protection on its own:

• Brute force and credential stuffing — capping login attempts per account and per IP sharply slows password guessing and the testing of stolen login–password pairs. That gives teams time to respond. (Brute force is trial-and-error password guessing; credential stuffing is the mass reuse of credentials stolen from other services.)
• Application-layer (L7) DDoS — rejecting requests above a threshold limits the impact of flooding costly endpoints. Volumetric attacks, which simply saturate the link, still need extra mitigation at the network edge.
• Scraping and API abuse — per-client limits hinder bulk data harvesting and resource enumeration.
• Resource exhaustion — rate limiting, especially when based on request cost, protects against single clients that eat up a disproportionate share of CPU, memory, or bandwidth.

Why does rate limiting matter for monitoring and SOC?

Rate limiting events are valuable signals for security and network monitoring teams (SOC is the security operations center; NDR is threat detection in network traffic). A sudden spike in 429 responses from one API key or address range is a signal: someone is trying to abuse the service, a client is misconfigured, or an attack is starting. Matching rejection counts against specific endpoints (e.g. login, password reset) helps tell credential stuffing apart from an ordinary traffic surge. Analyzing request patterns — how often they arrive, from which IPs and user agents, and how they spread across the day — reveals automation and bot traffic that simple threshold blocking may miss.

How does rate limiting differ from throttling?

The terms are often confused, but they differ in how they react to crossing the threshold. Rate limiting enforces a hard cap — requests above the threshold are rejected (usually 429). Throttling is softer: it accepts requests but slows their handling — delaying, queuing, or deprioritizing excess traffic instead of dropping it. In practice, throttling is often one possible response within a rate limiting policy, and many API gateways apply both together.

How should a client react to 429?

A 429 Too Many Requests response often includes a Retry-After header telling the client how long to wait before retrying (in seconds or as a date). Many APIs also add informational headers such as X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. A well-behaved client honors Retry-After and applies exponential backoff with jitter — it lengthens the gaps between retries and adds a small random offset, so retries do not arrive in synchronized waves. Ignoring these signals only deepens the overload.

Learn more

• API Security — API security often uses rate limiting to reduce abuse and control request volume.
• REST API — REST APIs commonly apply rate limiting to protect endpoints from excessive requests.
• Amplification Attack — Rate limiting can help limit the traffic used in amplification attacks.
• Reflection Attack — Rate limiting can reduce the impact of reflection attacks by capping request rates.