O que é rate limiting e como proteger uma API de solicitações excessivas?
Publicado em 2026-10-20 por frfrand
Qué es rate limiting, límites por usuario e IP, respuestas 429, ventanas temporales y cuándo puede perjudicar usuarios legítimos.
Rate limiting é uma técnica que limita quantas solicitações um cliente pode fazer durante um período ou sob determinadas regras. É usada para proteger APIs, evitar abusos e distribuir de forma razoável uma capacidade que não é infinita.
Se alguém enviar milhares de requisições por segundo ao seu formulário de login, talvez você não queira que todas sejam atendidas sem restrições.
Uma comparação com as entradas de um museu
Imagine um museu com espaço para cem visitantes simultâneos. Se deixar entrar mil pessoas de uma vez, a experiência se torna ruim para todos.
Os limites de solicitação cumprem uma função semelhante: permitem administrar o ritmo de acesso para que um cliente muito ativo não consuma todos os recursos do serviço.
Mas é preciso evitar uma política injusta. Se várias famílias chegarem no mesmo ônibus, bloqueá-las porque compartilham um endereço de origem também seria um erro.
O que pode ser limitado?
Você pode estabelecer regras por endereço IP, conta autenticada, token de API ou tipo de endpoint. Cada alternativa apresenta compensações.
Limitar apenas por IP pode afetar pessoas que compartilham uma conexão residencial, corporativa ou móvel. Limitar por usuário requer identificá-lo. Para endpoints críticos, podem ser aplicadas várias estratégias combinadas.
A lógica de negócios influencia: consultar um produto público não custa o mesmo que gerar um relatório pesado ou enviar um e-mail.
Como é implementado?
Uma estratégia simples é permitir uma certa quantidade de solicitações dentro de uma janela temporal. Também existem modelos como token bucket, que permitem rajadas controladas e recuperam capacidade progressivamente.
Não é necessário memorizar as fórmulas para compreender o objetivo: estabelecer um ritmo sustentável sem punir desnecessariamente os visitantes legítimos.
Em sistemas com vários servidores, a coordenação importa. Se cada instância contar solicitações separadamente, adicionar instâncias pode multiplicar acidentalmente o limite permitido.
O que é o erro HTTP 429?
Quando um cliente excede a política, o servidor pode devolver o status 429 Too Many Requests. Algumas respostas incluem Retry-After para indicar quando convém tentar novamente.
O aplicativo cliente deve respeitar os limites e não tentar novamente em um loop agressivo. Caso contrário, um sistema que está tentando se proteger receberá ainda mais tráfego.
Rate limiting e DDoS não são a mesma coisa
Os limites de aplicação ajudam com certos abusos, mas nem sempre podem parar um ataque volumétrico que satura a rede antes de chegar ao seu servidor.
Para esses cenários, são importantes defesas a montante, redes de distribuição e serviços especializados. O rate limiting é uma camada, não uma solução mágica contra todas as ameaças.
Exemplo: uma API de geração de relatórios
Uma API permite exportar relatórios que levam vinte segundos para serem preparados. Você pode limitar a quantidade de trabalhos simultâneos por conta e mover a geração para uma fila.
Isso protege o servidor e evita que uma pessoa lance centenas de trabalhos idênticos acidentalmente. Em vez de devolver erros inesperados, o sistema pode informar que a tarefa foi agendada ou que uma cota foi temporariamente atingida.
Erros habituais
Um limite idêntico para todas as rotas: uma consulta de status e uma exportação cara não têm as mesmas necessidades.
Não explicar a rejeição: o cliente interpreta 429 como uma queda se não souber quando tentar novamente.
Bloquear por IP sem contexto: usuários legítimos atrás da mesma rede acabam afetados.
Confiar no limite como autorização: uma pessoa sem permissões não deveria poder fazer uma operação nem uma única vez.
Como aplicar no ArduMaker?
Em uma API implantada em um VPS do ArduMaker, você pode implementar limites no backend ou em um proxy compatível, considerando quantas instâncias existem e onde o contador é compartilhado. O Redis pode participar em certos projetos, embora a escolha exata dependa da arquitetura.
Em uma frase: rate limiting permite dizer «até aqui, por agora» para proteger a disponibilidade do serviço. Funciona melhor quando responde ao custo real de cada ação e não se torna um obstáculo para usuários legítimos.
Fontes: RFC 6585: status 429 · Cabeçalho Retry-After.