Rate Limiting API: guia passo a passo para implementar

Rate limiting é a técnica que controla quantas requisições um cliente pode fazer a uma API em um intervalo de tempo. Sem ela, um único cliente mal configurado, ou mal-intencionado, pode consumir todos os recursos do servidor, degradando a experiência de todos os outros usuários. Neste guia, mostramos como implementar rate limiting em APIs REST passo a passo, desde a escolha do algoritmo até a configuração de respostas adequadas, com dicas para evitar os erros mais comuns.

Pré-requisitos

Antes de começar, verifique se você tem:

• Uma API REST funcional (em qualquer linguagem, usaremos exemplos conceituais).
• Acesso a um armazenamento de estado compartilhado, como Redis ou um banco de dados relacional.
• Conhecimento básico de middleware em sua framework (Express, Django, Flask, Spring Boot, etc.).

Passo 1: Defina o limite por cliente

A primeira decisão é quantas requisições cada cliente pode fazer. Não existe número universal: depende do seu caso de uso. Para uma API pública, 100 requisições por minuto é um ponto de partida comum. Para uma API interna, o limite pode ser maior. Considere também diferenciar planos: clientes gratuitos com 100 req/min, pagantes com 1000 req/min. Documente esses limites claramente, para que os desenvolvedores que consomem sua API saibam o que esperar.

Erro comum a evitar: definir um limite único para todos sem considerar picos legítimos de uso. Um cliente que faz 101 requisições em um minuto não é necessariamente um ataque, pode ser uma operação de sincronização. Use limites que reflitam o comportamento real dos seus usuários.

Passo 2: Escolha o algoritmo de rate limiting

Cada algoritmo tem um trade-off diferente entre precisão e custo computacional. Os mais comuns são:

• Token Bucket: cada cliente tem um balde com N tokens. A cada requisição, um token é removido. Tokens são reabastecidos a uma taxa fixa. Simples e eficiente, mas permite rajadas curtas.
• Sliding Window Log: mantém um registro de timestamps de cada requisição. Quando uma nova chega, remove os timestamps fora da janela e conta os restantes. Preciso, mas consome mais memória.
• Sliding Window Counter: combina a janela fixa com um contador deslizante. Mais leve que o log e mais justo que o token bucket.
• Leaky Bucket: processa requisições a uma taxa constante, enfileirando o excesso. Ideal para evitar rajadas, mas pode introduzir latência.

Dica: comece com Token Bucket se sua prioridade é simplicidade. Mude para Sliding Window Counter se precisar de maior precisão contra rajadas.

Passo 3: Armazene o estado em um sistema compartilhado

Rate limiting exige que o estado seja compartilhado entre todas as instâncias da sua API. Se você tem dois servidores rodando, cada um precisa saber quantas requisições o cliente já fez. Redis é a escolha mais comum por sua velocidade e suporte a comandos atômicos como INCR e EXPIRE. Uma chave típica no Redis seria rate_limit:cliente_id:minuto com valor sendo o contador e TTL de 60 segundos.

Erro comum a evitar: armazenar o estado em memória local de cada instância. Isso faz com que um cliente possa exceder o limite simplesmente alternando entre servidores. Sempre use um armazenamento compartilhado.

Passo 4: Implemente o middleware de verificação

Crie um middleware que intercepte cada requisição antes de chegar ao seu endpoint. A lógica básica é:

1. Identifique o cliente (por chave de API, IP ou token JWT).
2. Verifique o contador atual no Redis.
3. Se o contador excedeu o limite, retorne HTTP 429 Too Many Requests com uma mensagem clara.
4. Caso contrário, incremente o contador e prossiga.

Inclua cabeçalhos HTTP padronizados para que o cliente saiba seu estado: X-RateLimit-Limit (limite total), X-RateLimit-Remaining (requisições restantes) e Retry-After (tempo em segundos até poder tentar de novo).

Dica: não bloqueie requisições apenas com base no IP. Muitos usuários legítimos compartilham o mesmo IP (redes corporativas, NAT). Prefira identificar por chave de API sempre que possível.

Passo 5: Teste com cenários reais

Simule um cliente que envia requisições em rajadas e outro que faz requisições espaçadas. Verifique se:

• O limite é respeitado.
• A resposta 429 chega com os cabeçalhos corretos.
• O contador é resetado após a janela de tempo.
• Múltiplas instâncias da API compartilham o mesmo estado.

Use ferramentas como k6, Apache Bench ou até curl com loops para testar. Documente os resultados para ajustar os limites conforme necessário.

Erro comum a evitar: testar apenas com um cliente. O rate limiting precisa funcionar sob carga de múltiplos clientes simultâneos. Isso revela problemas de concorrência no Redis ou no banco de dados.

Checklist do que foi feito

• [ ] Definimos limites por cliente (ex.: 100 req/min).
• [ ] Escolhemos um algoritmo (Token Bucket, Sliding Window, etc.).
• [ ] Configuramos Redis (ou similar) como armazenamento compartilhado.
• [ ] Implementamos middleware com verificação e cabeçalhos HTTP.
• [ ] Testamos com cenários de rajada e múltiplos clientes.

Perguntas frequentes sobre rate limiting

Qual a diferença entre rate limiting e throttling?

Rate limiting define um número máximo de requisições em uma janela de tempo. Throttling é uma técnica mais ampla que pode incluir rate limiting, mas também pode significar reduzir a velocidade de processamento (ex.: atrasar requisições em vez de bloqueá-las).

Devo sempre usar Redis para rate limiting?

Redis é a escolha mais comum por velocidade e comandos atômicos. Para APIs com volume muito baixo (menos de 100 req/min), um banco relacional com índices pode funcionar. Para APIs distribuídas com alta concorrência, Redis é praticamente obrigatório.

Como lidar com requisições que ultrapassam o limite?

Retorne HTTP 429 Too Many Requests com o cabeçalho Retry-After indicando quantos segundos o cliente deve esperar. Inclua também uma mensagem no corpo da resposta explicando o motivo e onde encontrar a documentação.

Rate limiting resolve ataques DDoS?

Rate limiting ajuda a mitigar ataques de baixa e média intensidade, mas não substitui firewalls de aplicação (WAF) ou serviços de proteção DDoS dedicados. Um ataque distribuído com muitos IPs diferentes pode ainda assim sobrecarregar o servidor.