# Rate Limiting API: guia passo a passo para implementar

> Rate Limiting API é uma técnica de controle de requisições que limita o número de chamadas de um cliente a uma API em um intervalo de tempo específico. O guia passo a passo aborda desde a seleção do algoritmo adequado até a configuração de respostas de erro, fornecendo dicas para evitar falhas comuns na implementação.

*PosUp · Apps e Software · 24 de julho de 2026 · Patrícia Lemos*

Rate limiting é a técnica que controla quantas requisições um cliente pode fazer a uma API em um intervalo de tempo. Neste guia, mostramos como implementar passo a passo, desde a escolha do algoritmo até a configuração de respostas adequadas, com dicas para evitar os erros mais c

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 é:

- Identifique o cliente (por chave de API, IP ou token JWT).
- Verifique o contador atual no Redis.
- Se o contador excedeu o limite, retorne HTTP 429 Too Many Requests com uma mensagem clara.
- 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.

---

Fonte (canonical): https://posup.com.br/apps-e-software/rate-limiting-api-guia-passo-a-passo-para-implementar/