Where to apply limits and returning 429
40 min · Intermediate
A rate limiter needs two more decisions besides its algorithm: whom it counts (the key) and how it tells a client to slow down (a 429 response with Retry-After).
Topics in this lesson
- Choosing the key: user, IP, API key or endpoint
- Tiered limits, and stricter limits on login and OTP
- 429 Too Many Requests, Retry-After and X-RateLimit headers
- Reading code: a Spring HandlerInterceptor with the token bucket
- Distributed limits: why a shared counter is needed
Key points
- Count by the most precise identity: user id, then API key, then IP; IPs are shared through NAT.
- Use tiers for normal endpoints and strict, tier-free limits for login, OTP and password reset.
- Answer with
429,Retry-Afterand the normal error body; sendX-RateLimit-*headers on every response. - With several servers, keep counters in a shared store such as Redis (
INCR+EXPIRE, or a Lua script).
Interview questions this lesson answers
- How do you choose the rate-limit key?
- What is the problem with limiting by IP address?
- What should a rate-limited response look like?
- 429 or 503: which one when?
- Where would you implement the limit in a Spring Boot app?
- Your limiter works on one server. What changes with ten servers?
- What happens if Redis is down? Do you block everyone?
Sign in to continue this lesson
Create an account to read every lesson, practise with the exercises and keep track of your progress.