Como você implementa rate limiting com Redis?

Question

Accepted Answer

**Rate limiting** (restringir quantas requisições/ações são permitidas em uma janela de tempo) é um caso de uso comum do Redis — os contadores atômicos rápidos e TTLs do Redis o tornam ideal. Vários algoritmos existem (janela fixa, janela deslizante, token bucket), cada um com trade-offs.

## Janela fixa (mais simples)

```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
```

A abordagem de **janela fixa**: um contador atômico por (usuário, janela de tempo) com um TTL — incrementar por requisição, rejeitar quando sobre o limite. Simples e eficiente, aproveitando `INCR` atômico e expiração automática.

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

## Janela deslizante (mais suave)

```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 (permite bursts controlados)

```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
```

## Por que Redis é ideal para isso

```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.
```

## Por que isso importa

Implementar rate limiting com Redis é um caso de uso comum e prático, então entender isso é conhecimento valioso — rate limiting (proteger APIs e serviços do abuso, garantir uso justo, prevenir sobrecarga) é uma necessidade praticamente universal, e Redis é a ferramenta padrão para isso.

Entender **por que Redis é ideal** é fundamental: seus **contadores atômicos** (`INCR`) tornam a contagem de rate correta sob concorrência (sem race conditions/contagens perdidas), sua **velocidade** (em memória) adiciona latência mínima a cada requisição, **TTLs** lidam com limpeza de janela automaticamente, e crucialmente é **compartilhado entre servidores** — habilitando **rate limiting distribuído** onde todos os servidores de aplicação impõem um limite consistente (essencial em implantações multi-servidor, onde limites em memória por servidor não funcionariam).

Entender os **algoritmos** e seus trade-offs permite escolher apropriadamente: **janela fixa** (mais simples — um contador atômico por janela de tempo com um TTL, mas permitindo bursts de limite), **janela deslizante** (mais suave e precisa usando um sorted set de requisições com timestamp, a um custo de memória maior), e **token bucket** (permitindo bursts controlados enquanto limita a taxa média, frequentemente via script Lua para atomicidade).

Saber como implementar esses (especialmente o padrão simples e comum de janela fixa com `INCR` + `EXPIRE`) é habilidade prática e aplicável.

Como rate limiting é um requisito comum para proteger serviços, e como Redis (com seus contadores atômicos, velocidade, TTLs e compartilhamento entre servidores) é a ferramenta padrão e ideal para rate limiting distribuído, entender como implementá-lo com Redis — os algoritmos, seus trade-offs, e por que Redis se encaixa tão bem — é conhecimento valioso e frequentemente aplicável para construir serviços robustos e protegidos, uma das aplicações práticas mais comuns do Redis além de cache.