API Rate Limiter Calculator

Token Bucket accumulates tokens over time and allows short bursts when tokens are saved up — if no requests came in for 5 seconds, the bucket fills and the next burst can fire quickly. Leaky Bucket processes requests at a strictly constant output rate regardless of how they arrive, acting more like a queue with a fixed drain speed. Token Bucket is better when occasional bursts are acceptable; Leaky Bucket is better when the downstream system requires perfectly smooth traffic.

Fixed Window counters reset at fixed clock boundaries (e.g., every minute at :00). A client can send the full window quota in the last second of one window and immediately again in the first second of the next window — effectively sending 2× the intended rate without being throttled. Sliding Window algorithms solve this by evaluating the most recent N seconds at any point in time, with no hard resets.

Sliding Window Log stores every individual request timestamp, giving you mathematically exact rate limiting. Use it when precision is critical (financial transactions, audit-sensitive APIs). Sliding Window Counter uses just two counters with a weighted approximation, giving ~±10% accuracy at window boundaries. Use it when you need high scale and low memory — it is the algorithm behind Cloudflare's rate limiting and Nginx's limit_req_zone.

Burst capacity should reflect the largest legitimate traffic spike your API can absorb without degrading. A common rule: set burst capacity to 10–20% of your per-minute rate limit. For example, if your limit is 100 req/min (~1.67 req/s), a burst of 10–20 tokens lets clients make a batch of requests immediately, then they refill at the sustained rate. Set it too high and you lose protection against abuse; too low and normal clients hit 429 errors.

Sliding Window Counter uses approximately 74 bytes per user (two counters + timestamp + key overhead) regardless of traffic volume — very memory-efficient at any scale. Sliding Window Log scales with the number of requests per window: if your limit is 100 req/min and the window is 60 seconds, you store up to 100 timestamps (8 bytes each) plus key overhead, totaling ~850 bytes per active user. For 100,000 active users that is about 85 MB — manageable but worth planning for.

Return HTTP 429 Too Many Requests. Include the following headers: Retry-After (seconds until the client can retry), X-RateLimit-Limit (total allowed requests in the window), X-RateLimit-Remaining (requests left in the current window), and X-RateLimit-Reset (Unix timestamp when the window resets). This allows well-behaved API clients to back off automatically and retry intelligently without polling your API.