Não aconteceu uma, nem duas, nem três… Mas perdi as contas de quantas vezes já vi sistemas dando timeout por causa de excesso de conexões — seja por bugs internos, efeitos colaterais de integrações mal feitas, robos ou até mesmo por ataques simples como deny of service. 😬
E o pior: o timeout não vem com um
HTTP 429 (Too Many Requests), que avisa o cliente sobre o excesso pois tem algum mecanismo de controle de tráfego ativo. Ele chega com um belo 500 Internal Server Error… ou pior, um 504 Gateway Timeout. Ou seja, pro usuário, parece que o sistema caiu de vez.
E sabe o que é mais frustrante? Em muitos casos, bastava uma coisa simples pra evitar o desastre: limite de tráfego bem configurado. O famoso — e muitas vezes esquecido — Rate Limiting.
Aplicar limites não é só uma boa prática. É sobrevivência arquitetural, especialmente quando falamos de APIs públicas. (Mas não se engane: já vi muito sistema quebrar por causa de uma API interna mal protegida. Basta uma nova funcionalidade no upstream, e pronto: o downstream implode 😬).
Aliás, essa é uma daquelas perguntinhas que gosto de soltar quando estou entrevistando alguém: “Se você fosse criar uma API pública, o que levaria em consideração?”
Nem sempre a resposta vem com “rate limit”, mas quando vem, já sei que o básico tá no radar. E isso me dá abertura pra explorar até onde essa pessoa realmente entende de padrões de resiliência e segurança.
Com isso, vamos falar sobre Controle de Tráfego em APIs….
O que é Controle de Tráfego em APIs?
De forma simples: controle de tráfego é o conjunto de estratégias para evitar que sua API seja sobrecarregada por requisições — legítimas ou não.
Você define limites de consumo por usuário, IP, token, rota ou até por região geográfica. Assim, consegue proteger seu sistema contra picos repentinos de tráfego, prevenir abusos e garantir qualidade de serviço para todos.
E vale reforçar: na maioria dos casos, você não ativa um único tipo de limite, mas sim vários combinados. Por exemplo, pode limitar a quantidade de requisições por IP, restringir ações específicas por usuário (como criação de pedidos, envio de e-mails, login etc.), e ainda aplicar regras diferentes para ambientes de teste e produção.
Esse controle mais granular é essencial pra evitar que um único ponto de entrada derrube todo o sistema — e permite que você tenha respostas mais inteligentes e proporcionais, ao invés de simplesmente bloquear tudo ou deixar tudo liberado.
Nesse newsletter, vamos focar em uma das estratégias mais conhecidas e eficazes dentro do controle de tráfego: o
Rate Limiting.
Apesar de existirem outras técnicas (como throttling, quota management, circuit breakers, entre outras), o rate limiting é um dos primeiros mecanismos que você deve considerar quando pensa em proteger sua API de abusos e manter o sistema resiliente e estável.
Por que aplicar Rate Limiting?
Bom, depois da introdução você ainda tem dúvida, eu tenho uma pergunta pra você : “Por que você usa cinto de segurança?”. Não ficaria surpreso em ouvir uma resposta do tipo “Eu não uso pois me garanto no volante e só estou na cidade”, nesse caso só tenho algo a dizer … tenha esperança ! 👀
Você aplica Rate Limiting pra evitar:
✅
Que todos 100% dos usuários da API sejam afetados devido o comportamente de um único usuário que não representa nem 1% dos usuários do seu sistema
✅ Instabilidade interna causada por loops ou retries excessivos entre microsserviços.
✅ Sobrecarga no banco de dados ou fila de eventos por chamadas excessivas.
✅ Abusos voluntários ou involuntários, como bots ou usuários que criam scripts mal feitos.
✅ DoS (Denial of Service) – sim, limitar tráfego é uma primeira camada contra esse tipo de ataque.
✅ Estouro de orçamento em serviços pagos por requisição (sim, seu bolso também agradece 💸).
Mas… vale o tradeoff?
Como sempre falo no CaD, todo pattern é um pacote de tradeoffs. Não existe almoço grátis na arquitetura.
No caso de controle de tráfego, os principais desafios são:
⚠️ Overhead de Implementação – Configurar e manter limites por rota, IP ou token pode ser trabalhoso.
⚠️ Falsos positivos – Se mal configurado, pode bloquear usuários legítimos.
⚠️ Complexidade na Escalabilidade – Em arquiteturas distribuídas, aplicar rate limit consistente em obrigatoriamente passar por um proxy único (Ex. API Gateway, Load Balancer…), porém em alguns casos pode exige sincronização entre instâncias.
⚠️ Degradação da Experiência – Um sistema que devolve “429 Too Many Requests” a torto e a direito sem aviso prévio pode irritar seu cliente final.
Estratégias mais comuns de Rate Limit
Aqui vão algumas técnicas que você pode (e deve!) considerar:
🚦 Token Bucket – Distribui “fichas” ao longo do tempo; requisições só passam se houver ficha disponível.
📈 Leaky Bucket – Similar ao Token Bucket, mas com vazão constante. Ótimo para suavizar picos.
📊 Fixed Window / Sliding Window – Conta requisições por período de tempo (ex: 100 req/min). Sliding window é mais justo.
🧠 Rate Limiting Inteligente via API Gateway – Como no AWS API Gateway, Kong, NGINX, Traefik.
📍 Throttling baseado em contexto – Usuário VIP tem limite maior, rotas críticas têm limites mais baixos, e por aí vai.
Conclusão
No final das contas, Rate Limit é sobre garantir justiça, previsibilidade e estabilidade. Sem ele, você tá basicamente torcendo pra tudo dar certo. E entre torcer e arquitetar… acho que a escolha é óbvia, né? 😉
Se você curte conteúdos como esse e quer aprender os padrões e práticas que ajudam a construir sistemas escaláveis, seguros e resilientes, te convido pra fazer parte da Comunidade de Arquitetura Descomplicada (CaD).
Lá a gente não só fala de Rate Limit, mas também de todos os outros aspectos que fazem de você um(a) arquiteto(a) de verdade. 🔥
Abraços,
Douglas Mugnos
MUGNOS-IT 🚀
