Rate Limiting API: O Que É e Como Implementar

Rate limiting API é uma técnica que restringe o número de requisições que um cliente pode fazer a uma API dentro de um intervalo de tempo definido. Ele protege a infraestrutura contra abusos, garante disponibilidade para todos os usuários e ajuda a controlar custos operacionais.

O que é rate limiting e por que ele existe?

Rate limiting é um mecanismo de controle de tráfego. Ele define um teto de requisições por janela de tempo, como 100 chamadas por minuto por chave de API. Quando o cliente ultrapassa esse limite, a API responde com o status HTTP 429 (Too Many Requests) e, de preferência, com o cabeçalho Retry-After indicando quando tentar novamente.

A motivação não é apenas segurança. Um único cliente com um loop mal escrito pode consumir toda a capacidade de um servidor. Em APIs públicas, isso significa que outros desenvolvedores ficam sem resposta. Em APIs internas, pode significar aumento inesperado de custos com nuvem. O rate limiting distribui a capacidade de forma justa.

Quais são os principais algoritmos de rate limiting?

Existem quatro abordagens mais usadas, cada uma com um perfil diferente de precisão e custo computacional.

Fixed Window: conta requisições em blocos fixos de tempo, como de minuto em minuto. É simples de implementar com um contador no Redis, mas permite picos na virada da janela. Um cliente pode fazer 100 chamadas às 12h00m59s e outras 100 às 12h01m00s.

Sliding Window: suaviza o problema anterior ao considerar uma janela móvel. É mais preciso, porém exige armazenar timestamps ou usar estruturas como sorted sets, o que aumenta o uso de memória.

Token Bucket: mantém um balde de fichas que é reabastecido a uma taxa constante. Cada requisição consome uma ficha. Permite rajadas controladas até o limite do balde, o que é útil para clientes legítimos que fazem picos ocasionais.

Leaky Bucket: processa requisições a uma taxa fixa, enfileirando o excedente. É comum em cenários de streaming ou filas, mas pode adicionar latência perceptível.

A escolha depende do objetivo. Para APIs públicas com planos de uso, o token bucket costuma equilibrar bem simplicidade e flexibilidade. Para proteção contra ataques, o sliding window oferece maior precisão.

Como implementar rate limiting na prática?

A implementação pode ocorrer em três camadas: no API gateway, em um middleware da aplicação ou em um serviço dedicado.

No gateway (como Kong, NGINX ou Amazon API Gateway), a configuração é declarativa e não exige código. É a opção mais rápida para quem já usa essas ferramentas. Um middleware na aplicação dá mais controle sobre regras por usuário, rota ou plano. Já um serviço dedicado, como um cluster Redis, centraliza a contagem quando há múltiplas instâncias da API.

O ponto crítico é a atomicidade. Se duas instâncias leem o contador ao mesmo tempo e ambas o incrementam, o limite pode ser furado. Por isso, use operações atômicas, como INCR e EXPIRE no Redis, ou scripts Lua.

Defina também a chave de identificação: por API key, por IP, por usuário autenticado ou uma combinação. IP sozinho é frágil, pois NAT corporativo agrupa muitos usuários. API key é mais justo, mas exige autenticação prévia.

Quais boas práticas evitar erros comuns?

Comunique os limites de forma clara. Inclua cabeçalhos como X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset nas respostas. Isso permite que o cliente se adapte sem tentativa e erro.

Não use rate limiting como única defesa. Ele complementa, mas não substitui autenticação, validação de entrada e monitoramento. Um atacante distribuído pode contornar limites por IP.

Teste com carga realista. Ferramentas como k6 ou Locust ajudam a simular picos e verificar se o limite está sendo aplicado corretamente sob concorrência.

Documente os limites na referência da API. Desenvolvedores que entendem as regras constroem integrações mais resilientes e reduzem chamadas desnecessárias.

Resumo rápido

Rate limiting API controla quantas requisições um cliente pode fazer em um período. Escolha o algoritmo conforme a necessidade de precisão e rajada, implemente com operações atômicas e comunique os limites via cabeçalhos HTTP. Sem isso, sua API fica vulnerável a abusos e a picos que comprometem todos os usuários.

FAQ

O que acontece quando o limite de requisições é excedido?

A API deve responder com o status HTTP 429 (Too Many Requests). O ideal é incluir o cabeçalho Retry-After com o tempo em segundos para nova tentativa. O cliente deve respeitar essa orientação e implementar backoff exponencial para evitar novas violações.

Rate limiting é o mesmo que throttling?

Não exatamente. Rate limiting rejeita requisições que ultrapassam o limite. Throttling desacelera o processamento, enfileirando ou atrasando respostas. Na prática, muitos sistemas combinam os dois: rejeitam o excesso e suavizam picos dentro de uma margem aceitável.

Qual algoritmo de rate limiting devo escolher?

Depende do caso. Fixed Window é simples e suficiente para limites generosos. Sliding Window oferece precisão para segurança. Token Bucket permite rajadas controladas e é comum em APIs públicas. Leaky Bucket é útil quando a taxa de processamento precisa ser constante, como em filas.

Como identificar o cliente para aplicar o limite?

Use API key para clientes autenticados, pois é estável e justo. Para tráfego anônimo, combine IP com outras impressões digitais, como user-agent. Evite usar apenas IP em redes corporativas com NAT, pois muitos usuários compartilham o mesmo endereço.

Rate limiting pode ser implementado no Redis?

Sim. O Redis é uma escolha comum por ser rápido e suportar operações atômicas como INCR e EXPIRE. Você pode implementar Fixed Window com chaves que expiram ou Sliding Window com sorted sets. Para múltiplas instâncias da API, o Redis centraliza a contagem e evita inconsistências.

Quais cabeçalhos HTTP ajudam no rate limiting?

Os mais usados são X-RateLimit-Limit (total permitido), X-RateLimit-Remaining (restantes na janela), X-RateLimit-Reset (quando a janela reinicia) e Retry-After (tempo de espera após 429). Eles permitem que o cliente ajuste o ritmo sem tentativas cegas.