What is the best rate limiting algorithm?

Sliding window counter is the pragmatic default: it is nearly as accurate as a sliding log while storing two integers instead of a timestamp per request, and it resists the boundary-doubling trick that defeats fixed windows. Choose token bucket instead when short legitimate bursts are expected, such as a dashboard loading many resources at once.

Why does my rate limit allow twice the configured requests?

Two common causes. A fixed window resets on a calendar boundary, so a client can send a full allowance just before the reset and again just after, doubling the effective rate. Alternatively your counter is in process memory while you run multiple instances, in which case each instance enforces the full limit independently.

Can I rate limit reliably in serverless or edge functions?

Not with in-process state. Serverless instances start and stop unpredictably, and edge requests are served from whichever region is closest, so per-instance counters multiply the effective limit. Use a shared store: Redis with atomic increment, or a single-owner primitive such as Durable Objects at the edge.

Should I rate limit by IP address?

Only for anonymous traffic, and knowing it is blunt. Corporate NAT and mobile carriers place many users behind one address, while an attacker with a proxy pool controls many addresses. Authenticated routes should be limited by user ID or API key, and every route should have its own budget so a cheap endpoint cannot exhaust an expensive one's allowance.

What should a rate-limited response return?

HTTP 429 with a Retry-After header, plus RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset so well-behaved clients can back off correctly. Do not describe which rule fired or what the threshold is, and keep login responses indistinguishable from ordinary failed attempts so the limiter does not become an account enumeration oracle.

GUIDE · ABUSE BOUNDARY · UPDATED 2026-08-29

Rate limiting patterns that survive real traffic

Most rate limiting fails not because the algorithm is wrong but because the state is in the wrong place. Here is how the four common patterns actually behave, and why the store matters more than the maths.

Why fixed windows leak

The simplest limiter counts requests per calendar minute and resets at the boundary. It is easy to reason about and easy to defeat: send your full allowance in the last second of one window and again in the first second of the next, and you have doubled the intended rate through a legitimate-looking burst.

the boundary problem

# Limit: 100 requests per minute
12:00:59  → 100 requests  # window A, at limit
12:01:00  → 100 requests  # window B, at limit
→ 200 requests in a two-second span, no rule violated

For login endpoints and anything expensive, that doubling is the whole attack budget.

The four patterns and where each fits

Pattern	Cost	Boundary-safe	Best for
Fixed window	One counter per key	No	Coarse quotas where 2× overshoot is acceptable
Sliding log	Timestamp per request	Yes, exactly	Low-volume, high-value routes (password reset, payment)
Sliding window counter	Two counters per key	Approximately	The usual default: near-exact at a fraction of the memory
Token bucket	Tokens + timestamp	Yes	APIs that should tolerate short legitimate bursts

Sliding window counter is the pragmatic default. It weights the previous window by how far you are into the current one, so the boundary trick buys almost nothing, and it stores two integers instead of a list of timestamps.

sliding window counter

// weight the previous window by the remaining fraction of it
const elapsed = (now % windowMs) / windowMs;
const estimate = previousCount * (1 - elapsed) + currentCount;
if (estimate >= limit) return { action: 'block', reason: 'rate.window_exceeded' };

Token bucket is the right choice when bursts are legitimate — a dashboard loading twelve widgets on mount is not abuse. Tokens refill at a steady rate up to a ceiling; the ceiling is your burst tolerance, the refill rate is your sustained limit.

The real problem is shared state

Every pattern above assumes one counter that all request handlers can see. That assumption breaks quickly in modern deployments:

Multiple instances. An in-memory counter on each of six pods means each attacker gets six times the limit. In-memory limiting is per-process limiting, whatever the config says.
Serverless. Function instances are created and destroyed unpredictably. Module-scope state survives warm invocations and vanishes on cold starts — the limit becomes non-deterministic.
Edge runtimes. Requests land in whichever region is closest. A per-region counter multiplies the effective limit by the number of regions your traffic touches.

Pick the store before the algorithm. A crude fixed window over shared Redis enforces a real limit. A beautiful token bucket in process memory across twelve instances enforces twelve times what you configured.

Workable stores: Redis or Memcached with atomic increment for containers and VMs; Durable Objects or an equivalent single-owner primitive for edge runtimes; a database row with an atomic update for low-volume routes where the extra latency is fine.

Choosing the key

What you count matters as much as how you count.

IP address is the fallback for anonymous traffic, and it is blunt: corporate NAT and mobile carriers put thousands of users behind one address, while an attacker with a proxy pool has thousands of addresses. Never rate limit an authenticated endpoint by IP alone.
API key or user ID is precise and the right key for authenticated routes.
Route plus key. One global limit lets a cheap endpoint exhaust the budget that an expensive one needed. Give /api/login and /api/search separate budgets.
Behind a proxy, read the forwarded header carefully. Take the client IP your infrastructure guarantees, not the leftmost value a client can forge by sending its own X-Forwarded-For.

Responding to a limited request

Return 429 with a Retry-After header. Well-behaved clients back off; the ones that ignore it identify themselves as worth blocking outright.

429 response

HTTP/1.1 429 Too Many Requests
Retry-After: 30
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 30

Two things not to do: never return 429 with a body explaining which rule fired and what the threshold is — that is a tuning guide for the attacker. And on login endpoints, keep the response indistinguishable from a normal failed attempt, or the limiter becomes an account enumeration oracle.

Rate limits as policy

TJ Sentinel treats rate limiting as the abuse boundary: limits are declared per route in the policy file, the store is pluggable so the same policy runs against Redis in a container or a single-owner object at the edge, and a limited request produces the same rate.* reason code everywhere. Because the store is behind an interface, you can start with in-memory in development and move to shared state in production without rewriting the rules.

Generate a policy for your site →