Em sistemas distribuídos expostos à internet, os serviços sofrem variações extremas e imprevisíveis no padrão de tráfego. Picos sazonais de usuários legítimos, requisições automatizadas mal configuradas por clientes integradores, ataques de negação de serviço (DoS) e tentativas de brute-force competem pela mesma capacidade finita de processamento da infraestrutura.
Quando o número de conexões simultâneas excede a capacidade máxima suportada pelo banco de dados ou pelos nós computacionais da aplicação, o tempo médio de resposta se degrada exponencialmente, levando os servidores ao esgotamento completo de memória e CPU.
A Abordagem Tradicional: Escalonamento Reativo de Infraestrutura
A tentativa clássica de proteger o sistema contra picos de tráfego foca primariamente no autoescalonamento horizontal de contêineres (Horizontal Pod Autoscaler – HPA no Kubernetes). Conforme a CPU aumenta, novas instâncias são instanciadas para absorver o tráfego.
Limitações do Escalonamento Puramente Reativo
- Atraso de Reação (Cold Start): Criar e inicializar novas instâncias de contêineres e injetá-las no balanceador de carga leva minutos; o pico de requisições pode derrubar os nós ativos antes que a nova infraestrutura esteja pronta;
- Gargalo Centralizado no Banco: Escalar 50 instâncias da aplicação simplesmente transfere a carga para o banco de dados relacional compartilhado, que atinge o limite de conexões e trava;
- Explosão de Custos em Cloud: Ataques maliciosos ou scripts em loop de clientes geram cobranças desproporcionais de infraestrutura em nuvem (Denial of Wallet).
A Abordagem Moderna: Rate Limiting e Throttling
O Rate Limiting (Limite de Taxa) e o Throttling (Estrangulamento) protegem a integridade do sistema controlando ativamente o volume de requisições que uma aplicação aceita processar por unidade de tempo (ex: no máximo 100 requisições por segundo por token de API).
Quando o cliente atinge o limite estabelecido, o sistema rejeita as requisições excedentes na camada de borda (Edge / API Gateway), retornando imediatamente o código HTTP 429 Too Many Requests, acompanhado de cabeçalhos informativos como Retry-After.
Algoritmos Predominantes de Rate Limiting
A eficácia do controle de tráfego depende do algoritmo adotado pelo sistema de borda:
1. Token Bucket
Um “balde” acumula fichas (tokens) em uma taxa constante. Cada requisição consome um token. Se o balde estiver vazio, a requisição é descartada ou estrangulada.
- Vantagens: Permite absorver rajadas pontuais de tráfego (bursts) com rapidez sem comprometer o limite médio configurado.
- Uso: Padrão ouro em APIs públicas como Stripe, AWS e GitHub.
2. Leaky Bucket
As requisições entram em uma fila com tamanho fixo e são processadas e despachadas em uma taxa constante e estrita, como água pingando de um balde furado.
- Vantagens: Suaviza o tráfego que chega aos microsserviços internos, transformando fluxos espasmódicos em um fluxo perfeitamente linear e previsível.
- Uso: Proteção de serviços downstream com limites rigorosos de I/O em bancos legados.
3. Sliding Window Log / Counter (Janela Deslizante)
Calcula dinamicamente a taxa de requisições baseando-se no timestamp da janela de tempo móvel atual em vez de intervalos fixos de relógio.
- Vantagens: Elimina o problema clássico de borda (boundary burst) dos algoritmos de janela fixa, onde um cliente enviava o dobro do limite na virada do minuto.
- Uso: Limitação de chamadas sensíveis, como endpoints de login e autenticação.
Onde Implementar: Centralizado vs. Descentralizado
- Rate Limiting no API Gateway / Reverse Proxy (Recomendado): Implementado no Envoy, Kong, Nginx ou AWS API Gateway utilizando um cache distribuído (como Redis). Rejeita o excesso de tráfego na borda antes que o pacote atinja a rede interna dos microsserviços.
- Rate Limiting na Aplicação (In-App): Implementado diretamente no código da aplicação (via middlewares). Útil para regras de negócio altamente dinâmicas que dependem do contexto da requisição, mas consome CPU da própria aplicação para inspecionar requisições rejeitadas.
Quando Utilizar Cada Abordagem?
- Utilize Janela Fixa Simples quando: O tráfego for puramente interno entre ferramentas administrativas com tolerância a picos nas viradas de minuto.
- Utilize Token Bucket no Gateway quando: O sistema expuser APIs públicas comerciais com planos de assinatura categorizados (Tiered Pricing: Free, Pro, Enterprise).
- Utilize Leaky Bucket quando: Os microsserviços internos consumirem recursos não escaláveis (ex: exportação de relatórios pesados ou comunicação com sistemas bancários legados via mainframe).
