Concept explanation
Rate limits are backend safety rails. This game makes you choose limits based on traffic shape, fairness, dependency health, and the true cost of each operation.
All games
Rate Limit Architect
Choose rate limiting designs for realistic backend traffic patterns, from public APIs and login endpoints to queues, webhooks, and retry storms.
- Concept
- Rate limiting, fairness, backpressure, and abuse protection
- Difficulty
- Intermediate
- Play time
- 6-9 minutes
- Path
- Data & Performance
practice/rate-limit-architect Rate limit design score Play, get feedback, save local progress, and optionally submit a leaderboard score.
Playable game area
Use the controls below. Feedback appears immediately, and final scores are stored locally.
Leaderboard
Top 10 submitted scores. No account required.
Loading leaderboard...
Finish the game to load your latest local score.
Learning objectives
- Match rate limits to the resource being protected.
- Distinguish per-IP, per-user, per-account, cost-based, and concurrency limits.
- Use Retry-After, backoff, jitter, and circuit breakers to reduce overload.
How to play
- Read the traffic pattern and backend protection goal.
- Choose the limit strategy that protects the scarce resource without punishing normal users.
- Review the feedback to understand why the selected policy works or fails.
Scoring
- Best-fit policies earn full points.
- Weak but directionally relevant policies earn partial points.
- The final score is saved locally and can be submitted to the leaderboard.
Backend concept notes
Rate limiting is not just counting requests. Good limits protect the expensive resource: an account queue, a login target, a dependency, a database query, or an endpoint budget.
Production systems usually combine limits with clear 429 responses, Retry-After headers, backoff, jitter, observability, and safe retry behavior.
Common mistakes
- Using only per-IP limits for authenticated or account-level abuse.
- Applying the same raw request limit to cheap and expensive operations.
- Relying on client-side debounce as the only protection.
- Letting retries synchronize into a retry storm.
FAQ
Short answers for how this game fits backend interview and study practice.
Is a token bucket always better than a fixed window?
No. Token buckets are good for burst tolerance, but some workflows need concurrency limits, cost budgets, or per-account queue caps.
Should rate-limited APIs return 429?
Usually yes. 429 Too Many Requests plus Retry-After gives clients a clear signal to slow down.