Design a distributed rate limiter that caps how many requests a client (API key / IP) can make per time window.
How to approach it
Capacity estimation converts product numbers into engineering pressure. Go from daily active users to queries-per-second (QPS ≈ DAU × actions ÷ 86,400, with a 2–3× peak), then to storage (writes/day × payload × retention) and bandwidth (QPS × response size). You only need the order of magnitude — it tells you whether to design for read scaling, write scaling, or storage first.
Assumptions
| Assumption | Value |
|---|---|
| Total QPS | 1M/s |
| Distinct clients | 10M |
| Window | 1 minute |
| Counter size | ~16 B/client |
Derived numbers
| Quantity | Estimate |
|---|---|
| Limiter checks/s | 1M (one per request) |
| Counter memory | ~160 MB |
| Store latency budget | < 1ms |
| Hotspot risk | popular keys |
Note
Every request hits the limiter, so the counter store must be in-memory and sub-millisecond.