Design an API rate limiter from an empty canvas: per-client counters in memory in front of an API, adding only milliseconds, and stopping abusive clients before they reach it.
Unlock it once for 15 credits; everything inside it is free (runs, changes, Submit, results, hints). Sign in with Google to start; new accounts get free credits.
What it must do
Count each client’s requests in a sliding window and reject those over its quota with a 429.
Stop abusive clients and floods before they reach the API.
Add only a few milliseconds to every request.
Never reject well-behaved clients, even at peak.
Scale
1,000 requests a second from 50,000 API keys: 800 reads and 200 writes.
Each key may make 100 requests a minute; one counter check per request.
A sliding-window counter is about 100 bytes per key: 5 MB for every key, in memory.
Request types to route: read (80%, read), write (20%, write). Budget: $3,500 a month.
Estimate first
Counter memory for every API key (MB)
Counter checks a second at peak (2×) (per second)
Requests a second reaching the API in a 4,000 req/s scraping attack with a filter that stops 90% (req/s)
Monthly cloud cost of your design (USD)
The test cases
You start from an empty canvas. When you run the tests, each one simulates your design with its own traffic and failures:
Test
What it does
Passes when
Normal day
The normal day: the traffic in the brief, nothing broken.
Success ≥ 99.9%; p99 latency ≤ 40 ms (read); p99 latency ≤ 50 ms (write)
Peak: 2× traffic
At 5 s real traffic doubles for 8 s: every client is busy, none is over its quota.
Success ≥ 99.5%; p99 latency ≤ 50 ms (read)
Scrapers
At 5 s 4,000 requests a second of scraping traffic arrive for 10 s, alongside real users.
Attack blocked ≥ 85%; Success ≥ 99%
A server dies
At 4 s one server of the first app service on the request path dies for 10 s.
Success ≥ 99%
Budget: $3,500/month
The normal day's design must cost at most $3,500 a month.
Cost ≤ $3,500/month
Must include
Per-client counters in memory. Every request reads and bumps its client’s counter: it must be an in-memory store, or the limiter becomes the slowest part of the API.
A filter for abusive clients. Floods from a few abusive clients must be stopped at the edge, before they spend the API’s capacity.
The API being protected. The limiter sits in front of a real service that does the work.