Mission
Interactive Simulation
Before we explain anything — play. Push it until it breaks, then fix it.
Traffic
Rate Limiter
Break it
What just happened?
The flood of bot traffic saturated your API, so real users' requests failed too. A single global limit protected the API but couldn't tell bots from users — it rejected both. Keying the limit per client (API key or IP) throttled the handful of loud bots while quiet real users sailed through.
The concept
A rate limiter caps how many requests a client can make in a time window. It protects backends from abuse and accidental overload. Three classic algorithms: Fixed Window (simple, but bursty at window edges), Sliding Window (smoother, more accurate), and Token Bucket (allows controlled bursts while enforcing an average rate).
Trade-offs
Nothing is free. Here's what this solution costs you.
In the real world
Conceptually similar to API gateway rate limiting backed by a Redis-like store.
Mini quiz
Which algorithm best allows short bursts while keeping a steady average rate?
Interview me
The app becomes your interviewer. One question, in your own words.
Boss challenge
Stop API abuse
10,000 req/s of bot traffic is hitting a 3,000 req/s API alongside real users.
Goal: Keep the API under capacity (3K req/s) while rejecting under 5% of legitimate traffic.
Use the simulator above with no hints. These checks update live as you play.
Interview question
“Compare token bucket, fixed window, and sliding window. Where would you enforce limits, what key would you use, and how do you handle distributed counters?”