0Pricing
API Rate Limiting & Scalability Patterns · Lesson

Distributed Rate Limiting with Redis

Learn how to share rate limit state across multiple gateway and service instances using Redis, atomic operations, and Lua scripts to avoid race conditions.

Distributed Rate Limiting with Redis is a free API Rate Limiting & Scalability Patterns 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 API Rate Limiting & Scalability Patterns learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

The Multi-Instance Problem

When you run several gateway replicas, each one keeping its own in-memory counter means a client gets N x limit total — once per instance.

To enforce one global limit, every instance must read and update shared state.

Why Redis

Redis is the de facto choice for distributed rate limiting because it offers:

  • Sub-millisecond in-memory reads and writes
  • Atomic commands like INCR
  • Built-in expiry for automatic window resets
  • Lua scripting for multi-step atomic logic

A Naive Counter

The simplest fixed-window counter uses INCR plus EXPIRE:

The first request in a window creates the key and sets a TTL; later requests just increment.

INCR rate:user:42
-- if reply == 1 (first hit):
EXPIRE rate:user:42 60

The Race Condition

Running INCR then EXPIRE as two separate calls has a bug: if the process crashes between them, the key has no TTL and the limit never resets.

The fix is to make the check-and-increment atomic.

Atomicity with Lua

Redis runs a Lua script as a single atomic unit. We can check the count, increment, and set expiry without interruption.

local c = redis.call('INCR', KEYS[1])
if c == 1 then
  redis.call('EXPIRE', KEYS[1], ARGV[2])
end
if c > tonumber(ARGV[1]) then
  return 0
end
return 1

Calling the Script

From the gateway you invoke the script with EVAL, passing the key, the limit, and the window size.

A return of 1 means allow; 0 means reject with 429 Too Many Requests.

allowed = redis.eval(script, keys=['rate:user:42'], args=[100, 60])
if allowed == 0:
    return Response(status=429)

Sliding Window with Sorted Sets

For smoother limiting, store request timestamps in a sorted set. Remove old entries, count what remains, then add the new one.

ZREMRANGEBYSCORE rate:user:42 0 (now-window)
ZCARD rate:user:42
ZADD rate:user:42 now now

Returning Rate Limit Headers

Good gateways tell clients where they stand using standard headers:

  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • Retry-After on a 429

The Lua script can return remaining count alongside the allow flag.

Handling Redis Failures

What if Redis is unreachable? Two strategies:

  • Fail open — allow traffic; favors availability
  • Fail closed — reject traffic; favors protection

Most APIs fail open with a local fallback limiter to avoid a full outage.

Reducing Latency

Every limit check is a network hop. Cut overhead by:

  • Co-locating Redis near the gateway
  • Using connection pooling
  • Batching counters with a short local cache for very hot keys

Keying by Identity

The rate limit key defines what you are limiting. Common choices:

  • rate:ip:1.2.3.4 for anonymous traffic
  • rate:user:42 for authenticated users
  • rate:apikey:abc for API clients

Pick the most specific identity available so one abuser cannot exhaust a shared bucket.

Quick Check

Test your grasp of distributed limiting.

Recap

You learned to share rate limit state across instances:

  • A shared Redis store gives one global limit
  • Lua scripts make check-and-increment atomic
  • Sorted sets enable sliding windows
  • Decide fail open vs. closed for Redis outages

Frequently asked questions

Is the “Distributed Rate Limiting with Redis” lesson free?

Yes — the full text of “Distributed Rate Limiting with Redis” is free to read here on the web, and the API Rate Limiting & Scalability Patterns 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 API Rate Limiting & Scalability Patterns course, upgrade to CoddyKit PRO.

What will I learn in “Distributed Rate Limiting with Redis”?

Learn how to share rate limit state across multiple gateway and service instances using Redis, atomic operations, and Lua scripts to avoid race conditions. You practise API Rate Limiting & Scalability Patterns 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 API Rate Limiting & Scalability Patterns?

No prior experience is required. API Rate Limiting & Scalability Patterns 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 with Redis” 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 API Rate Limiting & Scalability Patterns lesson?

Yes. Every API Rate Limiting & Scalability Patterns 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

  1. API Gateway Integration Patterns
  2. Global vs. Per-Service Rate Limiting
  3. Dynamic Rate Limit Configuration
  4. Distributed Rate Limiting with Redis
← Back to API Rate Limiting & Scalability Patterns