# Rate Limiting em APIs: o que é e como protege seu sistema

> Rate limiting é um mecanismo de controle de requisições em APIs que define um limite máximo de chamadas por cliente em um intervalo de tempo específico. O rate limiting protege sistemas contra sobrecarga, ataques de força bruta e picos de tráfego, garantindo estabilidade operacional e previsibilidade de custos. A implementação utiliza algoritmos como token bucket ou fixed window para monitorar e restringir acessos.

*PosUp · Apps e Software · 09 de setembro de 2026 · Patrícia Lemos*

Rate limiting controla quantas requisições um cliente pode fazer a uma API em um intervalo de tempo. Sem ele, seu serviço fica exposto a sobrecarga, ataques e custos imprevisíveis. Veja como funciona e como aplicar.

Rate limiting é uma técnica que limita o número de requisições que um cliente pode enviar a uma API em um determinado período de tempo. Quando o limite é atingido, a API passa a recusar ou atrasar novas requisições, geralmente respondendo com o código HTTP 429 (Too Many Requests). Essa prática protege o servidor contra sobrecarga, ataques de força bruta e uso indevido, garantindo que o serviço continue disponível e rápido para todos os usuários.

## Como funciona o rate limiting na prática?

O rate limiting define uma regra simples: cada cliente, identificado por IP, chave de API ou token, pode fazer até X requisições por minuto, hora ou dia. Quando o cliente ultrapassa esse teto, a API responde com erro 429 e informa quando ele pode tentar novamente, geralmente no cabeçalho Retry-After.

Existem algoritmos comuns para implementar essa contagem. O fixed window conta requisições em janelas fixas de tempo, como 100 requisições por minuto. O sliding window faz o mesmo, mas com janelas contínuas, evitando picos exatamente no limite entre dois períodos. Já o token bucket usa uma metáfora de fichas: cada requisição consome uma ficha, e fichas são repostas a uma taxa constante. Cada abordagem tem prós e contras, e a escolha depende do seu cenário.

## Por que o rate limiting é essencial para a segurança de APIs?

Sem rate limiting, sua API fica vulnerável a três problemas principais. O primeiro é a sobrecarga acidental: um cliente mal configurado pode disparar milhares de requisições por segundo e derrubar o serviço para todos. O segundo é o abuso deliberado, como ataques de força bruta em endpoints de login ou scraping de dados em larga escala. O terceiro é o custo: se sua API roda em infraestrutura com cobrança por uso, cada requisição extra tem preço.

O rate limiting atua como uma comporta. Ele não impede que o ataque aconteça, mas limita o dano a um nível controlável. Em vez de o servidor processar 1 milhão de requisições fraudulentas, ele processa 100 e bloqueia o resto. Isso dá tempo para você detectar o padrão e agir, seja bloqueando o IP ou ajustando as regras.

## Quais são as boas práticas ao implementar rate limiting?

A primeira decisão é o que será limitado: IP, chave de API ou usuário autenticado. IP é fácil de implementar, mas pode punir usuários legítimos atrás de um mesmo NAT. Chave de API é mais precisa, mas exige que o cliente se autentique. Usuário autenticado é o mais justo, porém depende de um sistema de login.

Defina limites por endpoint, não apenas por API inteira. Um endpoint de login deve ter limite mais baixo que um endpoint de consulta pública, porque o risco de força bruta é maior. Inclua cabeçalhos de resposta como X-RateLimit-Limit e X-RateLimit-Remaining, para que o cliente saiba quanto ainda pode usar. Documente os limites no seu portal de desenvolvedores e responda com 429 quando o cliente exceder, em vez de simplesmente ignorar a requisição.

## O que acontece quando o limite é excedido?

Quando um cliente excede o limite, a API deve responder de forma clara e acionável. O código 429 indica que houve excesso de requisições. O cabeçalho Retry-After informa quantos segundos o cliente deve esperar antes de tentar novamente. O corpo da resposta pode incluir detalhes sobre qual limite foi atingido e quando ele será redefinido.

Para o cliente, a mensagem precisa ser útil, não apenas um erro seco. Um JSON com { "error": "rate_limit_exceeded", "retry_after": 30 } permite que o desenvolvedor trate o caso programaticamente. Para o servidor, registrar esses eventos ajuda a identificar padrões de abuso e ajustar os limites ao longo do tempo.

## Rate limiting é o mesmo que throttling?

Esses termos aparecem como sinônimos, mas há uma diferença sutil. Rate limiting recusa requisições quando o limite é atingido. Throttling, por outro lado, atrasa as requisições para suavizar o fluxo, em vez de recusá-las. Por exemplo, um servidor pode aceitar 10 requisições por segundo, mas colocar as extras em fila e processá-las aos poucos.

Na prática, muitas APIs usam os dois combinados. O rate limiting protege contra picos agressivos, enquanto o throttling garante que requisições legítimas não sejam simplesmente descartadas em momentos de alta demanda. A escolha depende do seu caso: se a requisição é idempotente e pode esperar, o throttling é mais amigável. Se o endpoint é crítico e precisa de resposta imediata, o rate limiting com recusa é mais seguro.

## Como escolher os limites certos para sua API?

Não existe um número mágico que sirva para todas as APIs. O limite ideal depende do seu público, da capacidade do servidor e do custo de cada requisição. Uma API interna usada por poucos serviços pode tolerar limites altos. Uma API pública com milhares de clientes precisa de limites mais conservadores.

Comece observando o tráfego real. Se 95% dos seus clientes fazem menos de 60 requisições por minuto, um limite de 100 por minuto é razoável. Monitore o percentual de respostas 429: se ele for alto, seus limites estão apertados demais. Se for quase zero, você pode estar deixando passar abusos. Ajuste aos poucos, com base em dados, não em achismo.

## Resumo rápido

Rate limiting é uma camada essencial de proteção para qualquer API que receba requisições externas. Ele limita o número de chamadas por cliente, evita sobrecarga e abusos, e mantém a performance previsível. Implemente com limites por endpoint, documente para seus usuários e monitore os erros 429 para calibrar as regras.

## Perguntas frequentes sobre rate limiting

### O que significa o código HTTP 429?

O código 429 (Too Many Requests) indica que o cliente enviou mais requisições do que o limite permitido em um determinado período. A resposta deve incluir o cabeçalho Retry-After, que informa quantos segundos o cliente precisa esperar antes de fazer uma nova tentativa.

### Como identificar um cliente no rate limiting?

O cliente pode ser identificado por IP, chave de API, token de acesso ou combinação desses fatores. IP é simples, mas pode afetar usuários legítimos. Chave de API é mais precisa, porque cada aplicação tem a sua própria. A escolha depende do nível de autenticação da sua API.

### Rate limiting afeta a experiência do usuário final?

Pode afetar, se os limites forem muito baixos ou mal configurados. Usuários legítimos podem receber 429 se compartilham o mesmo IP ou se a aplicação faz muitas chamadas em um curto intervalo. Por isso, é importante definir limites realistas e retornar mensagens claras para o cliente tratar o erro.

### Qual a diferença entre rate limiting e autenticação?

Autenticação verifica quem está fazendo a requisição, enquanto rate limiting controla quantas requisições essa pessoa ou sistema pode fazer. São camadas complementares: a autenticação impede acessos não autorizados, e o rate limiting impede que um acesso legítimo seja usado de forma abusiva.

### Rate limiting protege contra ataques DDoS?

Rate limiting ajuda a mitigar os efeitos de um DDoS, mas não é uma solução completa. Ele limita o volume de requisições que um único IP ou chave pode enviar, reduzindo o impacto. Para ataques distribuídos, com muitos IPs diferentes, é necessário combinar com outras defesas, como firewalls e serviços de proteção.

### Como testar se o rate limiting está funcionando?

Envie requisições em sequência até ultrapassar o limite configurado e verifique se a API responde com 429. Confira também os cabeçalhos X-RateLimit-Limit e X-RateLimit-Remaining para ver se os valores fazem sentido. Ferramentas de teste de carga podem simular múltiplos clientes e validar o comportamento sob pressão.

---

Fonte (canonical): https://posup.com.br/apps-e-software/rate-limiting-em-apis-o-que-e-e-como-protege-seu-sistema/