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

Question

Accepted Answer

## 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 with <5ms p95.
- Redis ops: 1 INCR + EXPIRE per request → 10k ops/s, pipelined, cluster sharded by k

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

Understand the problem

Attempt it yourself

Study the solution

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

Use cases

Solution ready — 2 min read

Join the discussion

Discussion (0)

KEEP THE
STREAK ALIVE.

Understand the problem

Attempt it yourself

Study the solution

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

Use cases

Solution ready — 2 min read

Join the discussion

Discussion (0)

KEEP THESTREAK ALIVE.

KEEP THE
STREAK ALIVE.