Back to roadmap
Module 10 · End-to-End Design DrillsDay 09935 min

Drill: Rate Limiter (Deep)

Distributed token bucket with consistency hazards.

← PreviousNext →
Day 099

Drill: Rate Limiter (Deep)

Client
client
Rate limiter
edge
Lua atomic
service
Redis
datastore
Signal path
Distributed token bucket
Client
client
flow
Rate limiter
edge
Rate limiter
edge
flow
Lua atomic
service
Lua atomic
service
flow
Redis
datastore
Memory hook

Rate Limiter (Deep): distributed token bucket with consistency hazards

Mental model

compose the pieces into a design story

Design lens

Lua atomicity vs network roundtrips.

Recall anchors
AlgorithmsAtomicitySharding

Why it matters

Building a global rate limiter requires atomic state at scale. Redis with Lua scripts implements token bucket exactly; sharding by key avoids hot keys. Sliding-log algorithms give precise smoothing at higher cost.

Deep dive

Lua script: atomically read tokens, compute refill, decide allow/deny.

Per-key shard handles high cardinality; per-host limits aggregate.

Clock skew across edges causes drift; align with NTP and use server time.

Demo / scenario

Implement 100 req/min per API key.

  1. Key: 'rate:{api_key}'; fields: tokens, last_refill.
  2. Lua: refill = (now - last_refill) * rate; tokens = min(cap, tokens + refill).
  3. If tokens >= 1: tokens-- → allow; else deny.
  4. TTL on key auto-expires inactive.

Tradeoffs

  • Lua atomicity vs network roundtrips.
  • Sliding window log is more accurate but stores history.
  • Approximate distributed limits are usually fine.

Diagram

Client
Rate limiter
Lua atomic
Redis
Distributed token bucket.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →