How would you design a rate limiter (token bucket vs leaky bucket)?

Step 1: Use Cases, Constraints, Assumptions, Back-of-Envelope

Use cases

We'll scope to handle only the core flows that expose the bottlenecks; everything else is deferred.

• User calls API — each request checks limiter (user_id / IP / API key) against budget (e.g., 100/min), 429 if over.
• Service refills — token bucket adds tokens at fixed rate, allows bursts up to capacity; leaky bucket drains at constant rate (smooth).
• Service windows — fixed vs sliding window counters for strict caps.
• Service distributes — Redis + Lua atomic counters, per-node vs global.

Out of scope

• Payment for overages, UI for quota, complex tiered plans beyond 2 tiers, DDoS mitigation beyond rate-limit.

State assumptions

• Budget 100 requests/min per user, burst 20; 1M DAU, avg 10 req/user/day → 10M req/day.
• QPS: 10M/86k≈116 avg, 1k peak; limiter must handle 10k checks/s