Rate limit distribuído com Redis: quando um servidor não basta

O rate limiting com contadores em memória funciona bem com um único servidor (Rate limiting em Node.js: como proteger suas APIs contra sobrecarga e abusos sem afetar a UX). Quando a aplicação roda em várias instâncias — ou em funções serverless —, cada uma conta separadamente. Um limite de 100 requisições por minuto vira 300 com três servidores, e o login protegido contra força bruta fica três vezes mais vulnerável.

A solução: um contador compartilhado

Todas as instâncias consultam e incrementam o mesmo contador num armazenamento central e rápido. O Redis é a escolha mais comum.

import { RedisStore } from 'rate-limit-redis'

export const loginLimiter = rateLimit({
  windowMs: 15 * 60_000,
  limit: 5,
  store: new RedisStore({ sendCommand: (...args: string[]) => redis.call(...args) }),
})

Algoritmos

• Janela fixa: simples; permite rajadas na virada da janela.
• Janela deslizante: distribuição mais justa.
• Token bucket: permite pequenas rajadas e controla a média — ótimo para APIs.

Cuidados

1. 1.E se o Redis cair? Decida: liberar (prioriza disponibilidade) ou bloquear (prioriza proteção). Para login, um limite local de emergência é um bom meio-termo (Degradação graciosa: funcionar pela metade é melhor que sair do ar).
2. 2.Chaves bem definidas: por IP, usuário, rota e combinações.
3. 3.Expiração automática das chaves para não acumular memória.
4. 4.Latência: o Redis próximo da aplicação.

Serverless

Funções sem estado exigem obrigatoriamente um contador externo (Serverless na Vercel: limites que você precisa conhecer).

O cliente também participa

Respostas 429 com Retry-After e clientes que respeitam o backoff (Gerenciando o erro 429 Too Many Requests: exponential backoff e retry no cliente).

Veja Segurança Anti-Hacker da We Codex ou fale com a gente.