Distributed Rate Limiting
Coordinate request limits across many app instances using Redis counters and atomic Lua scripts for fixed-window, sliding-window, and token-bucket algorithms.
Distributed Rate Limiting is a free Redis Caching & Messaging (Pub/Sub, Streams) lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Redis Caching & Messaging (Pub/Sub, Streams) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Local Limits Do Not Scale
An in-memory rate limiter only counts requests on one server. With many app instances behind a load balancer, you need a shared view of usage. Redis, being central and atomic, is the natural coordination point.
Fixed Window Counter
The simplest algorithm: a counter per time window. INCR the key; set a TTL equal to the window on first increment. Reject when the count exceeds the limit.
INCR rl:user:42:1716900000
EXPIRE rl:user:42:1716900000 60The Race Condition
Doing INCR then EXPIRE as two commands risks a key without a TTL if the client dies in between. An atomic Lua script fixes this by running both as one operation.
local c = redis.call('INCR', KEYS[1])
if c == 1 then redis.call('EXPIRE', KEYS[1], ARGV[1]) end
return cWhy Atomicity Matters
Across many instances, concurrent requests could otherwise read and write counters in interleaved order. Lua scripts run atomically on the server, so the entire check-and-increment happens with no interleaving.
Fixed Window Burst Problem
Fixed windows allow bursts at the boundary: a client can send a full window's worth at the end of one window and again at the start of the next, doubling the effective rate.
Sliding Window Log
A sorted set of request timestamps gives a precise sliding window. Drop old entries, count what remains, and add the new request, all in one script.
ZREMRANGEBYSCORE rl:user:42 0 (now-window)
ZCARD rl:user:42
ZADD rl:user:42 now nowToken Bucket
The token bucket allows controlled bursts. Tokens refill at a fixed rate up to a cap; each request consumes one. Store tokens and last-refill time in a hash and update atomically with Lua.
HSET rl:tb:user:42 tokens 10 ts 1716900000Refill Logic
On each request, compute elapsed time, add elapsed * rate tokens (capped at the bucket size), then allow the request if at least one token remains. The Lua script keeps this consistent across instances.
Choosing an Algorithm
Fixed window: cheapest, allows boundary bursts. Sliding log: precise but more memory. Token bucket: smooth with controlled bursts, great for APIs.
Returning Useful Headers
Tell clients about their limits: return remaining requests and reset time so well-behaved clients can self-throttle.
# X-RateLimit-Remaining: 7
# X-RateLimit-Reset: 1716900060Resilience Note
Decide a fallback if Redis is unreachable: fail open (allow traffic) for availability, or fail closed (deny) for protection. The right choice depends on whether the limit guards cost or correctness.
Quick Check
Test your understanding of distributed rate limiting.
Recap
You built distributed rate limiting on Redis: fixed-window counters, atomic Lua to avoid TTL leaks and races, sliding-window logs with sorted sets, and token buckets for smooth bursts. Centralizing the counters makes limits consistent across all app instances; choose your fail-open vs fail-closed fallback deliberately.
Frequently asked questions
Is the “Distributed Rate Limiting” lesson free?
Yes — the full text of “Distributed Rate Limiting” is free to read here on the web, and the Redis Caching & Messaging (Pub/Sub, Streams) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Redis Caching & Messaging (Pub/Sub, Streams) course, upgrade to CoddyKit PRO.
What will I learn in “Distributed Rate Limiting”?
Coordinate request limits across many app instances using Redis counters and atomic Lua scripts for fixed-window, sliding-window, and token-bucket algorithms. You practise Redis Caching & Messaging (Pub/Sub, Streams) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Redis Caching & Messaging (Pub/Sub, Streams)?
No prior experience is required. Redis Caching & Messaging (Pub/Sub, Streams) on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Distributed Rate Limiting” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Redis Caching & Messaging (Pub/Sub, Streams) lesson?
Yes. Every Redis Caching & Messaging (Pub/Sub, Streams) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Distributed Locks with Redis
- Leader Election Patterns
- Redis as a Coordination Service
- Distributed Rate Limiting