How would you design a rate limiter?

A rate limiter restricts clients to N requests per time window. Requirements: limit per user/IP/API key; configurable limits per endpoint; accurate distributed limiting across multiple servers; low latency (adding <5ms per request). Algorithm choice: Token bucket: allows bursts up to bucket size, smooth average rate; Sliding window counter: accurate, memory proportional to request count; Fixed window: simple, slight boundary race condition. Token bucket is the most common for API rate limiting. Storage: must be shared across app servers → Redis. Redis provides atomic operations essential for thread-safe counting. Implementation (Fixed Window with Redis): key = "rate_limit:{user_id}:{current_minute}"; INCR key; EXPIRE key 60; if count > limit: reject; Must be atomic — use Lua script or Redis MULTI/EXEC to prevent race conditions. Sliding Window (Redis Sorted Set): ZADD with score = timestamp of each request; ZREMRANGEBYSCORE removes old entries; ZCARD counts current requests. Accurate but O(n) per request. Distributed considerations: race conditions with multiple app servers? Use Redis atomic operations (INCR is atomic). What if Redis is down? Either fail open (allow all requests) or fail closed (deny all) — typically fail open with logging. Response: HTTP 429 with headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After. Advanced: tiered limits (free vs paid), per-endpoint limits, dynamic limits.