How do you implement rate limiting with Redis?

Question

Accepted Answer

**Rate limiting** (restricting how many requests/actions are allowed in a time window) is a common Redis use case — Redis's fast atomic counters and TTLs make it ideal. Several algorithms exist (fixed window, sliding window, token bucket), each with trade-offs.

## Fixed window (simplest)

```js
// allow N requests per time window using an atomic counter with a TTL
async function rateLimit(userId, limit = 100, windowSec = 60) {
  const key = `rate:${userId}:${Math.floor(Date.now() / 1000 / windowSec)}`;
  const count = await redis.incr(key);     // atomic increment
  if (count === 1) await redis.expire(key, windowSec);  // set TTL on first request
  return count <= limit;                    // allowed if under the limit
}
// → INCR is atomic (correct under concurrency); the key auto-expires each window
```

The **fixed window** approach: an atomic counter per (user, time-window) with a TTL — increment per request, reject when over the limit. Simple and efficient, leveraging atomic `INCR` and auto-expiry.

```text
✗ Limitation: bursts at window boundaries (2x limit possible across two adjacent windows)
```

## Sliding window (smoother)

```text
SLIDING WINDOW → tracks requests over a rolling time period (no boundary bursts)
  → often uses a SORTED SET: add each request with a timestamp score,
    remove old entries (ZREMRANGEBYSCORE), count remaining (ZCARD)
  ✓ More accurate/smooth  ✗ More memory and complexity
```

## Token bucket (allows controlled bursts)

```text
TOKEN BUCKET → tokens refill at a steady rate; each request consumes a token
  → allows bursts (up to the bucket size) while limiting the average rate
  → often implemented with a Lua SCRIPT for atomic check-and-consume
```

## Why Redis is ideal for this

```text
✓ ATOMIC counters (INCR) → correct under concurrency, no race conditions
✓ Fast (in-memory) → minimal latency added to each request
✓ TTL → automatic window cleanup (no manual expiry management)
✓ SHARED across servers → distributed rate limiting (all app servers use one Redis)
→ Redis is the standard tool for distributed rate limiting.
```

## Why it matters

Implementing rate limiting with Redis is a common, practical use case, so understanding it is valuable knowledge — rate limiting (protecting APIs and services from abuse, ensuring fair usage, preventing overload) is a near-universal need, and Redis is the standard tool for it.

Understanding **why Redis is ideal** is key: its **atomic counters** (`INCR`) make rate counting correct under concurrency (no race conditions/lost counts), its **speed** (in-memory) adds minimal latency to each request, **TTLs** handle window cleanup automatically, and crucially it's **shared across servers** — enabling **distributed rate limiting** where all application servers enforce one consistent limit (essential in multi-server deployments, where per-server in-memory limits wouldn't work).

Understanding the **algorithms** and their trade-offs lets you choose appropriately: **fixed window** (simplest — an atomic counter per time-window with a TTL, but allowing boundary bursts), **sliding window** (smoother and more accurate using a sorted set of timestamped requests, at higher memory cost), and **token bucket** (allowing controlled bursts while limiting the average rate, often via a Lua script for atomicity).

Knowing how to implement these (especially the simple, common fixed-window pattern with `INCR` + `EXPIRE`) is practical, applicable skill.

Since rate limiting is a common requirement for protecting services, and since Redis (with its atomic counters, speed, TTLs, and cross-server sharing) is the standard, ideal tool for distributed rate limiting, understanding how to implement it with Redis — the algorithms, their trade-offs, and why Redis fits so well — is valuable, frequently-applicable knowledge for building robust, protected services, one of the most common practical Redis applications beyond caching.