rate-limiting

Implement rate limiting by choosing an algorithm (token bucket is recommended for most APIs), storing counters in Redis, and returning 429 responses with Retry-After and X-RateLimit headers when limits are exceeded. Apply limits per-user for authenticated requests or per-IP for anonymous traffic.

Token bucket allows controlled bursts with O(1) memory and suits most APIs, while sliding window log provides precise enforcement with no edge-case bursts but uses O(n) memory storing each request timestamp. Fixed window is simplest but allows 2x bursts at window boundaries.

Use Redis with atomic Lua scripts that combine ZREMRANGEBYSCORE, ZCARD, and ZADD in a single operation to prevent race conditions across distributed servers. This ensures exactly the configured number of requests are allowed even under concurrent load.

Rate limiters should fail open, allowing requests when Redis or the storage backend is unavailable. Availability takes priority over strict enforcement, since blocking all traffic due to a cache outage is worse than temporarily unenforced limits.

Critical endpoints like login and password reset need stricter limits than general API routes, typically 5 attempts per 15 minutes per user or IP. This mitigates brute-force and credential-stuffing attacks without affecting normal users.