API › Module 3 › Lesson 2
Rate Limiting Implementation
Design quotas that stop abuse without breaking real users
Opening
Limits are a product decision
Rate limiting is not only “X requests per minute.” Choose keys (IP, user, API key, route), algorithms (token bucket, sliding window), and responses (429 + Retry-After) that match your threat model.
1. Practical design
Layered keys
Per-IP for anonymous; per-user/API-key for authenticated; stricter on /login.
Cost-aware quotas
Weight expensive routes higher (export = 10 units, health = 1).
GraphQL & batching
Count resolvers or query cost—not only HTTP requests.
Clear errors
Return 429 with Retry-After; avoid leaking whether a username exists.
Example headers clients can use
HTTP/1.1 429 Too Many Requests Retry-After: 30 X-RateLimit-Limit: 100 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 1710000030
2. Where to enforce
Prefer gateway + Redis/shared store so multiple app instances share counters. App-level limits still matter for business rules (e.g. 3 password resets / hour / account).
Knowledge Check
A good rate-limit response includes:
Multiple choice