Rate limiting

One client with a bug in a loop can send thousands of requests a second and take the API down for everyone. Password guessing, scraping the course catalog and signup spam are also stopped by limits.

Limits are set per key: IP, user id, API key, sometimes a specific endpoint. For example, the GitHub REST API allows 5,000 requests per hour for an authenticated user and 60 for an anonymous one. For login, 5 attempts per minute per IP and per account is sensible.

Fixed window counts requests in a window (say, a minute) with INCR and EXPIRE in Redis. Simple, but at the window boundary a client can make double the requests within a few seconds.

Sliding window smooths that boundary by weighting the previous window. Token bucket keeps a «bucket» of N tokens refilled at a constant rate: it allows short bursts up to the bucket size but caps the average rate. Stripe uses a token bucket in its write-up on rate limiters.

Leaky bucket lets requests through at a constant rate and queues or drops the excess. Good for protecting a slow external API with a hard limit.

When the limit is exceeded, return 429 Too Many Requests with a Retry-After header, and in normal responses headers like RateLimit-Remaining. Well behaved clients use them to back off instead of blindly retrying.

If the API runs on 10 copies, an in-memory counter in each gives a limit 10 times higher. So counters live in a shared Redis with atomic operations (a Lua script or INCR), and the check runs at the gateway so a request is rejected before any business logic.