Rate Limiter Config Calculator

Token Bucket accumulates credits (tokens) over time up to a burst cap. Requests consume tokens; if empty, they're rejected. It's great for bursty traffic because it allows short bursts while enforcing a sustained average. Sliding Window tracks the exact count of requests in the last N seconds, rolling forward with each request. It's more accurate and immune to boundary attacks, but costs more memory (O(requests) per user). For most public APIs, Token Bucket is the practical choice; use Sliding Window when fairness is critical.

Burst capacity is the maximum number of requests allowed in a short spike before the rate limiter kicks in. For a Token Bucket with 100 req/s and burst=200, a client can fire 200 requests instantly, then is limited to 100/s thereafter. Too low a burst frustrates legitimate users during peak load (e.g., app startup, page loads). Too high allows abuse. A common rule of thumb: set burst to 2-5x your sustained RPS for user-facing APIs.

Fixed Window divides time into fixed slots (e.g., 0-60s, 60-120s). A client can send the full limit at 59s, wait 1s for the window to reset, then send the full limit again at 60s — effectively doubling the rate at the boundary. Example: limit 100 req/min → attacker sends 100 at t=59s + 100 at t=60s = 200 in 2 seconds. Sliding Window eliminates this by always looking at the last N seconds from now, not from a fixed start time.

Return 429 Too Many Requests when a specific client has exceeded their rate limit — always include a Retry-After header. Return 503 Service Unavailable when your entire service is overloaded globally (e.g., circuit breaker tripped). The key difference: 429 is per-client, 503 is system-wide. Well-behaved clients will back off on 429. Nginx returns 503 by default for limit_req overflow — override with 'limit_req_status 429'.

Single-server rate limiters break when you have multiple app instances (each has its own counter). Use a shared store: Redis is the standard choice. Libraries like rate-limit-redis (Node.js) or python-redis-rate-limit plug into your existing rate limiter. For Token Bucket or Sliding Window, use Redis Lua scripts (shown in the Redis tab above) to make the check-and-increment atomic. For high-throughput systems, consider a sidecar approach (Envoy, Istio) or a dedicated rate limiting service like Envoy's global rate limit service.

Leaky Bucket processes requests at a constant output rate (the 'leak') regardless of input burst. Excess requests either queue up (up to queue depth) or are dropped immediately. Unlike Token Bucket which allows bursts to pass through, Leaky Bucket smooths them out — output is always steady. Use it to protect downstream services that can't handle bursts: payment processors, third-party APIs with their own rate limits, or database connections. The tradeoff: legitimate burst traffic gets artificially delayed or dropped.