API Rate Limiting é a técnica que restringe o número de requisições que um cliente pode fazer a uma API dentro de uma janela de tempo definida, protegendo a infraestrutura contra sobrecarga, abuso e custos descontrolados. É um dos pilares de qualquer arquitetura de API moderna em produção.
TL;DR
- Rate Limiting controla o fluxo: define quantas requisições um cliente pode fazer por minuto, hora ou dia, retornando HTTP 429 (Too Many Requests) quando o limite é excedido, conforme especificado na RFC 6585.
- Quatro algoritmos dominam o mercado: Fixed Window, Sliding Window, Token Bucket e Leaky Bucket, cada um com trade-offs entre precisão, performance e complexidade de implementação.
- Empresas como GitHub (5.000 req/h), Twitter (300 req/15min) e Stripe (100 req/s) usam Rate Limiting em escala para garantir estabilidade, justiça entre clientes e proteção contra ataques de negação de serviço.
Como funciona o API Rate Limiting?
API Rate Limiting é o mecanismo que limita o número de requisições que um cliente pode fazer a uma API em determinado período.
O sistema funciona com três componentes essenciais: um identificador do cliente (geralmente API Key, token JWT, IP ou user ID), um contador que registra quantas requisições foram feitas e uma janela de tempo que define o período de medição. Quando o cliente excede o limite configurado, o servidor responde com status HTTP 429 e cabeçalhos informando quando o limite será resetado.
Contadores e armazenamento de estado
Os contadores precisam de armazenamento rápido e distribuído, já que APIs modernas rodam atrás de múltiplos servidores. Redis é o padrão de facto da indústria para esse caso de uso, com operações atômicas como INCR e EXPIRE que permitem incrementar contadores e definir TTL em uma única operação. Memcached, DynamoDB e bancos in-memory também são usados, mas Redis lidera por sua simplicidade e performance, processando centenas de milhares de operações por segundo em uma única instância.
Janelas de tempo
A janela de tempo define o intervalo no qual o limite é aplicado. Janelas curtas (segundos) protegem contra picos abusivos; janelas longas (horas, dias) controlam consumo agregado e custos. A maioria das APIs públicas combina múltiplas janelas: o GitHub aplica 5.000 requisições por hora para usuários autenticados e 60 por hora para requisições anônimas, enquanto o Twitter limita 300 requisições por janela de 15 minutos em endpoints de timeline.
Identificação do cliente
A precisão do Rate Limiting depende de identificar corretamente quem está fazendo a requisição. As estratégias mais comuns são: por IP (simples, mas vulnerável a NAT compartilhado e proxies), por API Key (preciso, mas exige autenticação), por user ID (ideal para APIs autenticadas) ou combinações híbridas. APIs sérias usam abordagens em camadas, aplicando limites mais restritivos para tráfego anônimo e mais generosos para clientes autenticados com planos pagos.
Para que serve o Rate Limiting?
Rate Limiting serve para proteger a infraestrutura, garantir justiça entre clientes, controlar custos e prevenir abusos.
Sem essa proteção, uma única aplicação cliente mal configurada pode consumir todos os recursos do servidor em segundos, derrubando o serviço para todos os outros usuários. Os principais casos de uso incluem proteção contra ataques de força bruta em endpoints de autenticação, mitigação de DDoS de camada 7, controle de custos em APIs que dependem de serviços pagos por requisição (como OpenAI ou Anthropic), e implementação de tiers comerciais (free, pro, enterprise) onde cada plano tem limites diferentes.
Outro uso fundamental é a estabilização de capacidade. Imagine uma API que aguenta 10.000 requisições por segundo: sem Rate Limiting, um cliente único pode consumir toda essa capacidade durante um pico, deixando os demais sem resposta. Com limites por cliente bem calibrados, a capacidade é distribuída de forma justa e previsível.
Algoritmos de Rate Limiting
Fixed Window
O algoritmo Fixed Window é o mais simples: divide o tempo em janelas fixas (por exemplo, a cada minuto cheio) e mantém um contador por janela. Quando o contador atinge o limite, todas as requisições subsequentes são rejeitadas até a próxima janela começar. Sua simplicidade é tanto vantagem quanto desvantagem: implementação trivial em poucas linhas de código com Redis, mas sofre do problema de burst nos limites. Um cliente pode fazer 100 requisições no último segundo de uma janela e mais 100 no primeiro segundo da próxima, totalizando 200 requisições em apenas 2 segundos quando o limite era 100 por minuto.
Sliding Window
O Sliding Window resolve o problema do burst calculando uma janela deslizante que considera a porcentagem da janela anterior. Existem duas variantes: Sliding Window Log (mantém um log de timestamps de todas as requisições, alta precisão mas custoso em memória) e Sliding Window Counter (combina contador da janela atual com proporção da anterior, menos preciso mas eficiente). A Cloudflare publicou um artigo técnico explicando como usa Sliding Window Counter em seu rate limiting de borda, processando bilhões de requisições por dia com erro estatístico inferior a 0,003%.
Token Bucket
O Token Bucket é o algoritmo mais popular em APIs comerciais. O conceito: cada cliente tem um balde virtual com capacidade máxima de tokens. Tokens são adicionados a uma taxa constante (refill rate); cada requisição consome um token. Se o balde está vazio, a requisição é rejeitada. A grande vantagem é permitir bursts controlados: um cliente que ficou inativo acumula tokens e pode enviar várias requisições rapidamente quando voltar, desde que respeite a capacidade máxima do balde. A AWS API Gateway usa Token Bucket em suas configurações de throttling, com parâmetros de burst limit (capacidade do balde) e rate limit (taxa de refill).
Leaky Bucket
O Leaky Bucket trata as requisições como uma fila com taxa de saída constante. Imagine um balde com um furo no fundo: independentemente da velocidade com que a água entra, ela sai a uma taxa fixa. Se o balde transborda, requisições são descartadas. A diferença crítica para o Token Bucket é que o Leaky Bucket suaviza o tráfego de saída, sendo ideal quando o objetivo é proteger sistemas downstream que não toleram bursts (como bancos de dados ou serviços legados). Muitos sistemas de mensageria e proxies de telecom usam Leaky Bucket por essa característica de smoothing.
Comparação dos algoritmos
| Algoritmo | Vantagens | Desvantagens | Complexidade | Caso de uso ideal |
|---|---|---|---|---|
| Fixed Window | Implementação trivial; baixo consumo de memória; performance alta | Permite burst de até 2x o limite nas bordas das janelas | Baixa | APIs internas, MVPs, limites grosseiros |
| Sliding Window | Alta precisão; sem problema de burst; distribuição justa | Maior consumo de memória (log) ou complexidade matemática (counter) | Média a alta | APIs públicas com SLA rigoroso |
| Token Bucket | Permite bursts controlados; intuitivo para clientes; flexível | Pode permitir picos que sobrecarregam downstream | Média | APIs comerciais com tiers, integrações de terceiros |
| Leaky Bucket | Suaviza tráfego de saída; protege sistemas downstream | Penaliza usuários legítimos durante picos esporádicos | Média | Proxies, gateways, sistemas com backend frágil |
Como implementar Rate Limiting
A implementação correta de Rate Limiting acontece em camadas, cada uma protegendo a próxima e oferecendo granularidade diferente. A arquitetura ideal combina três níveis.
Camada 1: API Gateway ou CDN de borda
Esta é a primeira linha de defesa e deve absorver o máximo de tráfego abusivo antes que ele chegue à aplicação. Serviços como Cloudflare, AWS API Gateway, Kong, NGINX Plus e Traefik oferecem rate limiting nativo configurável por IP, header customizado ou geolocalização. O ganho aqui é evitar que requisições abusivas consumam recursos do banco de dados e da aplicação. A Cloudflare, por exemplo, bloqueia ataques DDoS de camada 7 nessa camada, processando dezenas de terabits por segundo de tráfego globalmente.
Camada 2: Aplicação
Limites de negócio (por usuário, por API Key, por endpoint específico) ficam na aplicação. Bibliotecas maduras existem para todos os stacks: express-rate-limit e rate-limiter-flexible no Node.js, django-ratelimit no Python, rack-attack no Ruby, Bucket4j no Java e Laravel Throttle no PHP. O armazenamento deve ser distribuído (Redis) para funcionar corretamente atrás de load balancers com múltiplas instâncias.
Camada 3: Banco de dados e serviços críticos
Mesmo após passar pelas camadas anteriores, operações pesadas como exportações em lote ou consultas complexas devem ter limites próprios. PostgreSQL oferece statement_timeout, conexões podem ser limitadas via PgBouncer e operações específicas podem usar semáforos distribuídos. A Stripe documenta publicamente que aplica limites separados para operações de leitura e escrita, e limites mais restritos para criação de Charges e Customers.
Cabeçalhos HTTP padrão
Comunicar o estado do rate limiting ao cliente é essencial. A RFC 6585 estabelece o status 429 (Too Many Requests). A draft IETF RateLimit Header Fields for HTTP padroniza os cabeçalhos RateLimit-Limit, RateLimit-Remaining e RateLimit-Reset. Implementações maduras também enviam Retry-After indicando quantos segundos o cliente deve esperar antes de tentar novamente.
Erros comuns ao implementar Rate Limiting
- Usar contadores em memória local sem Redis: Em ambientes com múltiplas instâncias atrás de um load balancer, contadores locais permitem que um cliente faça N x limite requisições (onde N é o número de instâncias). O estado precisa ser compartilhado.
- Identificar clientes apenas por IP: Redes corporativas, NATs móveis e CGNAT compartilham IPs entre milhares de usuários. Bloquear por IP pode banir empresas inteiras por causa de um único abusador. Sempre combinar com identificadores adicionais.
- Não diferenciar endpoints: Aplicar o mesmo limite global para um endpoint de login (que deve ser muito restrito contra brute force) e um endpoint de leitura de dados públicos é um erro grave. Cada endpoint tem seu próprio perfil de risco.
- Esquecer dos cabeçalhos informativos: Retornar 429 sem dizer ao cliente quando ele pode tentar de novo força implementações com backoff exponencial agressivo, piorando o problema. Sempre enviar
Retry-AftereRateLimit-Reset. - Configurar limites baseados em achismo: Limites precisam ser calibrados com base em uso real. Monitore percentis (P95, P99) de requisições por cliente antes de definir números arbitrários que podem quebrar integrações legítimas.
- Não testar comportamento sob carga: Rate Limiting que funciona em desenvolvimento pode colapsar em produção. Teste com ferramentas como k6, JMeter ou Locust simulando milhares de clientes simultâneos antes de subir a feature.
- Aplicar o mesmo algoritmo para tudo: Endpoints diferentes têm necessidades diferentes. Login pede Fixed Window curto e severo; APIs de leitura pedem Token Bucket generoso; webhooks pedem Leaky Bucket para não sobrecarregar consumers.
API Rate Limiting e a Shiftmind
A Shiftmind atua há anos na implementação de APIs robustas e escaláveis para clientes B2B que dependem de integrações estáveis com sistemas internos, parceiros e plataformas externas. Nossa equipe de desenvolvimento aplica padrões de rate limiting em todas as camadas dos projetos, desde APIs REST customizadas até webhooks de integração com ERPs e CRMs.
Nos projetos de criação de sites WordPress e desenvolvimento WordPress corporativo, configuramos rate limiting no nível da REST API do WordPress para proteger contra abuso, força bruta em wp-login.php e enumeração de usuários. Para plataformas de e-commerce B2B com APIs de integração, aplicamos Token Bucket por API Key, garantindo que parceiros tenham SLA previsível e que picos de um cliente não afetem os demais.
O serviço de suporte e manutenção WordPress inclui monitoramento contínuo de endpoints críticos e ajuste fino dos limites conforme o crescimento do tráfego. Em conjunto com nossa segurança de websites, o rate limiting age como camada complementar ao WAF, bloqueando padrões de abuso antes que se tornem incidentes. Essa abordagem em profundidade é o que diferencia projetos amadores de implementações de nível corporativo.
Perguntas frequentes sobre API Rate Limiting
Qual o melhor algoritmo de rate limiting?
Não existe um algoritmo universalmente melhor. Para APIs comerciais com múltiplos tiers de clientes, Token Bucket é a escolha mais comum porque permite bursts controlados e é intuitivo para os clientes entenderem. Para endpoints sensíveis como login, Fixed Window curto é suficiente e simples. Para proteger sistemas downstream frágeis, Leaky Bucket suaviza o tráfego. Sliding Window é ideal quando precisão é crítica e o custo computacional adicional é aceitável. A maioria das APIs maduras combina algoritmos diferentes por endpoint.
Como diferenciar usuários para aplicar limites?
A identificação ideal usa múltiplas camadas: API Key ou token JWT para clientes autenticados (mais preciso), user ID quando disponível (para APIs internas), IP como fallback para tráfego anônimo (ciente das limitações de NAT) e fingerprinting de browser para casos especiais. Limites devem ser hierárquicos: por API Key (limite por cliente), por usuário dentro do cliente e por endpoint específico. APIs como Stripe e GitHub aplicam limites separados por organização, por usuário e por endpoint, criando proteção em profundidade.
Rate Limiting protege contra ataques DDoS?
Rate Limiting protege contra ataques DDoS de camada 7 (aplicação) de baixa a média intensidade, mas não é suficiente contra ataques volumétricos de camada 3/4 que saturam a banda da rede. Para proteção completa contra DDoS, é necessária uma combinação: CDN com proteção volumétrica (Cloudflare, AWS Shield, Akamai), WAF para padrões maliciosos, rate limiting na borda para abuso de API e rate limiting na aplicação para proteção de negócio. Cada camada tem seu papel; nenhuma sozinha resolve.
Quando retornar HTTP 429?
O status HTTP 429 (Too Many Requests), definido na RFC 6585, deve ser retornado sempre que o cliente excede o limite configurado. A resposta deve incluir o cabeçalho Retry-After indicando em quantos segundos o cliente pode tentar novamente (ou um timestamp HTTP absoluto). É boa prática também enviar RateLimit-Limit, RateLimit-Remaining e RateLimit-Reset em todas as respostas (não apenas quando bloqueia), permitindo que clientes bem comportados façam backoff preventivo antes de atingir o limite.
Rate Limiting afeta a experiência do usuário?
Rate Limiting mal configurado degrada drasticamente a experiência: usuários legítimos sendo bloqueados, mensagens de erro genéricas e ausência de informação sobre quando tentar novamente. Bem implementado, ele é invisível para o uso normal e age apenas em casos de abuso real. As práticas que garantem boa experiência incluem: calibrar limites com base em P99 de uso real, comunicar limites na documentação, enviar cabeçalhos informativos em todas as respostas, oferecer mensagens de erro claras com instruções de retry e fornecer dashboards onde clientes pagos podem ver seu consumo atual.
Termos relacionados
- API
- API Gateway
- API Key
- Algoritmo
- Algoritmo de Busca
- Algoritmo de Ordenação
- Abstração
- Acoplamento
- ActiveRecord
- Agile (Metodologia Ágil)
- AJAX
- Amazon Alexa SDK
- Android
- Android Studio
- Angular
- Anotação
- Anti-Pattern
- Apache Spark
Conclusão
API Rate Limiting é infraestrutura crítica, não um item opcional. Implementações bem calibradas protegem a aplicação, garantem justiça entre clientes, controlam custos e oferecem SLA previsível. A escolha do algoritmo, da camada de aplicação e dos limites específicos depende do contexto de cada API, mas o princípio é universal: nenhuma API séria roda em produção sem rate limiting.
Última atualização: Junho/2026.
Precisa implementar APIs robustas com rate limiting de nível corporativo no seu projeto? A Shiftmind tem experiência em arquitetura de APIs escaláveis, integrações B2B e desenvolvimento WordPress profissional. Entre em contato e converse com nossos especialistas.
