~/posts/systems-design/designing-a-rate-limiter.md
Designing a Rate Limiter from Scratch
systems design

Designing a Rate Limiter from Scratch

Token bucket, sliding window, fixed window — every algorithm explained with trade-offs. Plus how Redis makes distributed rate limiting trivially correct.

1 min read by admin api distributed-systems rate-limiting redis
~/posts/systems-design/designing-a-rate-limiter.md $ cat designing-a-rate-limiter.md
Designing a Rate Limiter from Scratch

Why Rate Limiting Matters

Without rate limiting, a single misbehaving client can exhaust your API capacity. Rate limiting is your first line of defense against abuse, runaway automation, and accidental DDoS.

Token Bucket

jhgfvbjhgfhjgf
hgyfd
jhgf

A bucket holds N tokens. Each request consumes one token. Tokens refill at a fixed rate. Bursts are allowed up to bucket capacity. Simple, efficient, widely used.

Sliding Window Log

For each user, store a log of request timestamps. On each request, remove timestamps older than the window, count remaining, compare to limit. Precise but memory-intensive.

Redis + Lua

Distributed rate limiting requires atomicity. A Lua script in Redis combines the check-and-decrement into a single atomic operation — no race conditions, no locks.