Limite de requisições
Algoritmos para limitar o uso de uma API e proteger o serviço contra abuso e sobrecarga.
As decisões de limite de requisições são cinco: onde aplicar o limite, qual algoritmo usar, quais valores escolher, o que fazer quando o armazenamento de contagens falha e como comunicar a recusa.
Onde aplicar
| Camada | Vantagens | Limites |
|---|---|---|
| CDN ou firewall de aplicação | Barra o tráfego antes de chegar à sua infraestrutura; bom contra ataques de volume | Conhece o IP e a rota, mas não o usuário ou o plano dele |
| Gateway de API ou proxy reverso | Um lugar só para todas as rotas; Nginx, Kong, Envoy e os gateways da nuvem têm o recurso pronto | Limites por usuário exigem que o gateway entenda a autenticação |
| Aplicação | Conhece o usuário, o plano, o custo de cada operação | Código a manter; o pedido já consumiu algum recurso ao chegar |
As camadas se complementam. Uma combinação comum: limites largos por IP na borda, contra volume e robôs; limites por cliente e por plano na aplicação ou no gateway; e limites específicos para rotas sensíveis, como login e envio de SMS.
Qual algoritmo
| Situação | Algoritmo |
|---|---|
| A maioria das APIs | Balde de fichas: permite rajadas curtas e controla o ritmo médio |
| Limites diários ou mensais de plano ("10 mil chamadas por mês") | Janela fixa por período: a virada no início do mês é aceitável |
| Login e rotas contra força bruta | Janela deslizante, por conta e por IP, com bloqueio crescente |
| Proteção simples, onde o dobro na virada não importa | Janela fixa com INCR e expiração |
Quais valores
Limites tirados do nada costumam ser apertados demais, bloqueando clientes legítimos, ou largos demais, sem proteger nada. Uma forma de chegar a valores razoáveis:
- Medir o uso real: o percentil 99 de pedidos por minuto dos clientes atuais.
- Dar folga: o limite fica algumas vezes acima do uso normal.
- Respeitar a capacidade: a soma dos limites dos clientes mais ativos não deve passar do que o sistema aguenta.
- Começar só observando: registrar quem passaria do limite, sem recusar, por alguns dias.
- Diferenciar por plano e por rota: uma busca cara pode ter um limite menor que uma leitura simples.
Quando o Redis falha
Se o armazenamento das contagens ficar indisponível, o limitador precisa decidir:
| Escolha | Consequência | Quando usar |
|---|---|---|
| Deixar passar (fail open) | A API continua funcionando, sem limite por um tempo | O padrão para a maioria das rotas: uma falha do limitador não deve derrubar o serviço |
| Recusar (fail closed) | A API para de atender as rotas protegidas | Rotas em que o abuso é pior que a indisponibilidade: envio de SMS pago, login |
Em qualquer caso, a falha precisa gerar alerta: deixar passar sem ninguém saber é ficar sem proteção.
Comunicar a recusa
HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 1
RateLimit-Policy: "padrao";q=10;w=2
RateLimit: "padrao";r=0;t=1
{
"type": "https://api.loja.com.br/erros/limite-excedido",
"title": "Limite de requisições excedido",
"status": 429,
"detail": "Tente novamente em 1 segundo."
}| Cabeçalho | Significado |
|---|---|
Retry-After | Segundos até poder tentar de novo; padronizado e entendido por muitas bibliotecas de cliente |
RateLimit-Policy e RateLimit | A política e o estado atual (quantos restam, em quanto tempo renova), num formato em padronização no IETF |
X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset | Os cabeçalhos informais usados por muitas APIs antes da padronização |
Enviar o estado do limite também nas respostas de sucesso permite que clientes bem-comportados diminuam o ritmo antes de serem recusados.
O lado do cliente
| Prática | Por quê |
|---|---|
Respeitar o Retry-After | Tentar antes só gera mais recusas |
| Intervalo crescente com variação aleatória | Mil clientes recusados no mesmo instante não devem voltar todos no mesmo instante |
| Ler o estado do limite nas respostas de sucesso | Diminuir o ritmo antes da recusa |
| Limitar a própria concorrência | Disparar 500 chamadas paralelas garante recusas, como mostra o tópico de concorrência |
Resumo da decisão
- Camadas: por IP na borda, por cliente e plano na aplicação ou no gateway, específicos nas rotas sensíveis.
- Balde de fichas como padrão; janela fixa para cotas mensais.
- Contagem compartilhada, no Redis, com operação atômica.
- Valores medidos, começando só com observação.
- Falha do Redis: deixar passar, com alerta, salvo rotas críticas.
429comRetry-After, e o estado do limite em todas as respostas.
O próximo nível mostra o balde de fichas num script Lua, chamado das cinco linguagens e testado contra o Redis.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Definir os limites da minha API
Quero definir os limites de requisições da minha API. Pergunte quem consome a API, quais rotas são mais caras ou sensíveis, se há planos com cotas diferentes e qual infraestrutura existe (CDN, gateway, Redis). Ajude a decidir: 1. Em quais camadas aplicar limites. 2. O algoritmo para cada caso. 3. Como chegar aos valores a partir do uso real, começando só com observação. 4. O comportamento quando o Redis falhar, rota por rota. 5. Os cabeçalhos e o corpo da resposta 429. Termine com uma tabela de limites por rota e por plano.
Proteger o login contra força bruta
Quero proteger a rota de login da minha aplicação contra tentativas de senha em massa. Pergunte qual linguagem e infraestrutura eu uso. Explique: 1. Por que limitar só por IP ou só por conta não basta. 2. Como combinar limites por conta e por IP com janela deslizante. 3. Bloqueio crescente: atrasos cada vez maiores depois de falhas seguidas. 4. Como evitar que o limite seja usado para bloquear a conta de outra pessoa de propósito. 5. Como isso se combina com segundo fator e verificação de senhas vazadas.
Limites no gateway ou na aplicação
Quero decidir se aplico os limites de requisições no gateway de API, no proxy reverso ou na própria aplicação. Pergunte qual infraestrutura eu uso. Compare as opções: o que cada camada sabe sobre o pedido, o custo de manter, a precisão com várias instâncias, a capacidade de limitar por plano e por custo da operação. Mostre a configuração de limite no meu gateway ou proxy, se houver, e recomende uma combinação de camadas.