Why Rate Limiting Matters

Rate limiting protects your API from abuse, prevents resource exhaustion, and ensures fair usage across clients. Without it, a single bad actor or buggy client can take down your service. Every production API needs rate limiting — it's not optional, it's infrastructure.

Token Bucket Algorithm

The token bucket adds tokens at a fixed rate and each request consumes one. Tokens accumulate up to a maximum (burst size). This allows short bursts while maintaining an average rate. It's the most popular algorithm — used by AWS, Stripe, and most API gateways. Implementation with Redis is straightforward using MULTI/EXEC or Lua scripts.

Sliding Window Algorithms

Sliding window log stores timestamps of every request and counts entries within the window. Precise but memory-intensive. Sliding window counter is a hybrid — it uses fixed windows but interpolates between the current and previous window to approximate a sliding count. This gives near-precise results with minimal memory overhead.

Fixed Window Counter

The simplest approach: count requests per time window (e.g., 100 requests per minute). Reset at window boundaries. The weakness: a client can send 100 requests at 0:59 and 100 more at 1:00, effectively doubling the rate. Use sliding windows to prevent this edge case.

Distributed Rate Limiting

In multi-server deployments, each server needs a shared counter. Redis is the standard choice — atomic operations, sub-millisecond latency, and built-in expiration. For global rate limiting across regions, consider Redis Cluster or a dedicated service like Envoy's rate limit service.

Rate Limit Response Headers

Follow the IETF draft standard: RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset. Return 429 Too Many Requests when limits are exceeded. Include a Retry-After header so clients know when to retry. Good API clients use these headers to self-throttle before hitting limits.

Implementation Patterns

Implement rate limiting as middleware — before your route handlers. Apply different limits per endpoint (auth endpoints get stricter limits). Use API keys or user IDs as rate limit keys, not just IP addresses. For public APIs, combine IP-based and key-based limiting. Consider tiered limits based on subscription plans.

Conclusion

Start with token bucket for most use cases. Use Redis for distributed deployments. Always return rate limit headers. Test your rate limiter under load to ensure it performs correctly at scale. A well-implemented rate limiter is invisible to good clients and protective against bad ones.