Rate Limiting em APIs: o que é e como implementar

Toda API tem um limite de quanto tráfego consegue suportar antes de degradar ou cair — e a forma padrão de controlar isso é o rate limiting: a técnica que define quantas requisições um cliente pode fazer dentro de um intervalo de tempo. A prática deixou de ser só um detalhe de infraestrutura. A OWASP renomeou a categoria correspondente no API Security Top 10, o IETF está padronizando os cabeçalhos HTTP que comunicam esses limites ao cliente, e até APIs de modelos de linguagem, como as da Anthropic e da OpenAI, usam o mesmo princípio para controlar tokens processados por minuto. Este guia explica os conceitos, os algoritmos mais usados e como implementar um limitador na prática.

O que é rate limiting

Rate limiting é o controle de quantas requisições um cliente — identificado por IP, chave de API, token de usuário ou conta — pode fazer a uma API dentro de uma janela de tempo. Quando esse limite é ultrapassado, o servidor normalmente responde com o código HTTP 429 Too Many Requests, recusando a chamada em vez de processá-la.

É diferente de quota. Rate limit controla picos curtos (por exemplo, 100 requisições por minuto), enquanto quota controla um volume total num período mais longo (por exemplo, 1 milhão de chamadas por mês). O Azure API Management trata os dois como políticas separadas, segundo a documentação da Microsoft: rate-limit-by-key limita a taxa por chave e devolve 429 quando estourada, enquanto quota-by-key controla volume ou banda acumulados e devolve 403 Forbidden com um cabeçalho Retry-After indicando quando tentar de novo.

Por que toda API precisa de limites

A ausência de rate limiting é tratada como risco de segurança, não só de performance. Na edição 2019 do OWASP API Security Top 10, o problema aparecia como "Lack of Resources & Rate Limiting". Na edição 2023, a categoria foi renomeada para "Unrestricted Resource Consumption" — mudança que desloca o foco do sintoma (faltam limites) para a causa raiz: a API permite que um cliente consuma CPU, memória, armazenamento ou banda sem restrição. Segundo a OWASP, esse tipo de falha abre caminho tanto para negação de serviço quanto para ataques de força bruta e enumeração contra endpoints de autenticação e busca de dados.

Os algoritmos mais usados

Existem quatro abordagens clássicas para implementar rate limiting, cada uma com um trade-off diferente entre simplicidade e precisão.

Janela fixa (Fixed Window)

Conta requisições dentro de blocos de tempo fixos, como a cada minuto cheio. É simples e barato de implementar, mas tem um problema conhecido: um cliente pode enviar o limite inteiro nos últimos segundos de uma janela e o limite inteiro de novo nos primeiros segundos da janela seguinte, dobrando na prática o tráfego permitido num curto intervalo.

Janela deslizante (Sliding Window)

Corrige a distorção da janela fixa recalculando a contagem de forma contínua, ponderando a janela anterior e a atual (ou registrando timestamps individuais). É mais precisa, mas consome mais memória e processamento, especialmente em sistemas distribuídos.

Token bucket

Cada cliente tem um "balde" com um número máximo de tokens, reabastecido a uma taxa constante. Cada requisição consome um token; se o balde está vazio, a requisição é recusada. O algoritmo permite rajadas controladas — o cliente pode gastar tokens acumulados de uma vez — o que o torna a escolha mais comum entre provedores de API. É o algoritmo usado pela Anthropic na API do Claude, segundo a documentação da empresa.

Leaky bucket

Funciona de forma inversa ao token bucket: as requisições entram numa fila e saem, ou seja, são processadas, a uma taxa fixa e constante, "vazando" de forma previsível. É útil quando o objetivo é suavizar picos de tráfego para um backend que não tolera rajadas, ao custo de adicionar latência às requisições que ficam na fila.

Como GitHub, AWS e Azure implementam limites na prática

Comparar como grandes provedores documentam seus próprios limites ajuda a calibrar o que é razoável implementar:

• GitHub REST API: 60 requisições por hora para chamadas não autenticadas e 5.000 por hora para autenticadas (limite primário). Um limite secundário à parte também restringe a no máximo 100 requisições concorrentes, compartilhadas entre REST e GraphQL, 900 pontos por minuto na REST API e 90 segundos de tempo de CPU a cada 60 segundos reais, segundo a documentação do GitHub. O Bytezine já cobriu outro mecanismo de controle de acesso do GitHub, a [allowlist de servidores MCP para o Copilot](/artigo/github-allowlist-mcp-copilot).
• Amazon API Gateway: o padrão de conta é 10.000 requisições por segundo em regime constante, com rajada de até 5.000, por região — limite que pode ser aumentado sob pedido ao suporte da AWS, segundo a documentação oficial. Para comparar os três grandes provedores de nuvem de forma mais ampla, veja o comparativo entre [AWS, Azure e Google Cloud](/artigo/aws-vs-azure-vs-gcp-2026) do Bytezine.
• Azure API Management: usa as políticas rate-limit-by-key (limite de taxa, resposta 429) e quota-by-key (limite de volume, resposta 403 com Retry-After); nenhuma das duas está disponível no tier Consumption, segundo a documentação da Microsoft. O Bytezine já mostrou como configurar limites no [Azure AI Gateway tier do API Management](/artigo/azure-ai-gateway-tier-api-management-preview), lançado em preview em agosto.
• APIs de modelos de linguagem: Anthropic e OpenAI limitam tanto por requisições por minuto quanto por tokens processados por minuto — a Anthropic separa entrada e saída em métricas próprias e sobe os limites por níveis de uso (tiers) conforme o gasto acumulado, segundo a documentação das duas empresas. Quem quer estimar consumo de tokens antes de esbarrar no limite pode usar a [calculadora de tokens e custo de IA](/calculadora-tokens) do Bytezine.

Implementando um rate limiter na prática

Para ilustrar o funcionamento do token bucket, o algoritmo mais comum, veja uma implementação simplificada em Python. Ela guarda o estado em memória, o que só funciona para uma única instância do servidor; em produção, com múltiplas instâncias, o estado precisa ficar num armazenamento compartilhado, como Redis, para que todas as réplicas apliquem o mesmo limite.

import time

class TokenBucket:
    def __init__(self, capacity: int, refill_rate: float):
        self.capacity = capacity          # tokens máximos no balde
        self.refill_rate = refill_rate    # tokens adicionados por segundo
        self.tokens = capacity
        self.last_check = time.monotonic()

    def allow_request(self) -> bool:
        now = time.monotonic()
        elapsed = now - self.last_check
        self.last_check = now

        # reabastece o balde proporcionalmente ao tempo passado
        self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)

        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False


# 100 requisições permitidas em rajada, reabastecendo 10 por segundo
limiter = TokenBucket(capacity=100, refill_rate=10)

def handle_request():
    if not limiter.allow_request():
        return {"status": 429, "body": "Too Many Requests"}
    return {"status": 200, "body": "OK"}

Cabeçalhos HTTP e o padrão em desenvolvimento pelo IETF

Hoje cada provedor usa nomes de cabeçalho próprios para informar limites, como variações de X-RateLimit-Limit e X-RateLimit-Remaining. O IETF trabalha num rascunho, o draft-ietf-httpapi-ratelimit-headers, atualmente na versão 11, para padronizar dois cabeçalhos: RateLimit, que informa o limite atual e quanto ainda resta, e RateLimit-Policy, que descreve a política aplicada. Segundo o próprio IETF, o documento ainda é um Internet-Draft, não uma RFC publicada, e não obriga nenhum algoritmo específico de throttling — define apenas o formato da informação trocada entre servidor e cliente.

Rate limiting e LGPD: o que observar

Aplicar rate limiting normalmente envolve identificar quem está fazendo a requisição — por IP, e-mail, CPF em endpoints de consulta ou ID de usuário — e guardar essa identificação, ainda que por pouco tempo, em contadores e logs. Isso é tratamento de dado pessoal sob a LGPD (Lei 13.709/2018), mesmo quando o único objetivo é proteger a própria API. Vale, no mínimo: evitar logar o dado bruto quando um hash ou ID interno resolve o mesmo problema; definir um tempo de retenção curto para os contadores de rate limit, já que eles perdem valor depois que a janela expira; e documentar essa finalidade específica na base legal do tratamento. Este texto é informativo e não substitui orientação jurídica — o [checklist de LGPD para startups](/artigo/lgpd-checklist-startups-2026) do Bytezine detalha como estruturar esse tipo de decisão.

Erros comuns ao implementar rate limiting

• Aplicar o mesmo limite para todos os endpoints, ignorando que uma busca complexa custa muito mais que uma leitura simples de cache.
• Não devolver os cabeçalhos que informam o limite restante, forçando o cliente a descobrir o limite por tentativa e erro.
• Manter o estado do limitador só em memória local, o que quebra em qualquer ambiente com mais de uma instância do serviço.
• Confundir rate limiting com proteção contra DDoS: um limitador de aplicação ajuda, mas não substitui um WAF ou um serviço de mitigação na borda da rede.
• Ignorar picos legítimos, como o reprocessamento em lote de um cliente confiável, sem oferecer um caminho de exceção, como uma chave dedicada ou um tier mais alto.

Rate limiting não é um recurso opcional de infraestrutura madura — é parte do contrato básico de qualquer API que aceita tráfego de terceiros. Escolher o algoritmo certo, devolver os cabeçalhos corretos e tratar com cuidado os dados usados para identificar quem está fazendo a requisição resolve, ao mesmo tempo, um problema de disponibilidade, um requisito de segurança da OWASP e, no caso brasileiro, uma obrigação de privacidade.