# Design a Rate Limiter — System Design: Architecture, Scale and Trade-offs

Source: https://www.skillbyai.com/en/system-design/sd-rate-limiter

> Design a distributed rate limiter with token buckets, Redis counters and helpful rate-limit response headers.

## Token bucket

Each client has a bucket refilled at a fixed rate up to a cap. A request spends one token; if the bucket is empty, reject with 429. It allows short bursts.

## Distributed state

With many API servers, counters must be shared. Keep them in Redis with atomic increments and per-key TTLs so any server enforces the same limit.

## Tell the client

Return `X-RateLimit-Remaining` and `Retry-After` headers so well-behaved clients back off instead of hammering.

**Quiz:** Which algorithm naturally permits a short burst above the steady rate?

- [x] Token bucket
- [ ] Fixed window counter
- [ ] Leaky bucket (as a queue)
- [ ] Sliding window log with no cap

*Answer:* Token bucket. Accumulated tokens let a client spend several at once, up to the bucket cap.