Quando integramos nosso sistema a serviços externos que impõem rate limits, precisamos nos adaptar para evitar falhas e manter a comunicação fluindo de forma consistente. Basicamente, rate limit é um limite de quantas requisições podemos fazer em um determinado intervalo de tempo. Se excedemos esse limite, o serviço externo pode bloquear ou atrasar nossas requisições (usualmente retornando um código de status como 429 Too Many Requests). Neste artigo, vamos discutir os principais cuidados e estratégias para lidar com integrações onde o rate limit é um fator crítico.
1. Entendendo o Rate Limit
Antes de adotar soluções complexas, entenda a política de rate limit oferecida pelo serviço externo:
- Limite de Requisições por Segundo (ou por Minuto)
Exemplo: 100 requisições por minuto. - Limite por Conta ou por IP
Alguns serviços aplicam um limite baseado na conta (API key), outros usam limites por endereço IP. - Comportamento de Bloqueio ou Atraso
Em alguns casos, você recebe respostas com status 429 e um cabeçalho indicando quando pode reenviar a requisição. Em outros, pode ocorrer uma diminuição de throughput ou até banimento temporário.
Quanto mais detalhes você souber, melhor poderá arquitetar a solução.
2. Estratégias de Controle de Fluxo (Throttling)
Para respeitar o limite de requisições imposto, você pode adotar diversos padrões de throttling que garantem que seu sistema não ultrapasse os limites configurados.
2.1 Bucket Tokens (Token Bucket)
O Token Bucket é uma estratégia clássica em que um “balde” acumula “tokens” ao longo do tempo e cada requisição consome um token. Se o balde ficar vazio, a requisição aguarda ou é rejeitada.
- Vantagem: Simples de entender e implementar.
- Desvantagem: Requer manutenção de um contador ou lista de tokens, possivelmente distribuído se seu sistema for escalável em vários nós.
2.2 Leaky Bucket
Parecido com o token bucket, mas a “vazão” de requisições sai do balde a uma taxa fixa.
- Vantagem: Ajuda a suavizar picos de carga, mantendo uma taxa de saída uniforme.
- Desvantagem: Se surgirem grandes picos, as requisições podem se acumular na fila e gerar latências significativas.
2.3 Janela Fixa (Fixed Window) e Janela Deslizante (Sliding Window)
Outras estratégias computam quantas requisições foram feitas dentro de uma janela de tempo fixa ou “deslizante” para decidir se novas requisições serão aceitas.
- Fixed Window: “Pacotes” de tempo (ex.: 1 minuto) onde o número de requisições é contado.
- Sliding Window: Utiliza um timestamp para cada requisição e calcula a janela dinâmica em relação ao tempo atual.
3. Retentativa (Retry) e Backoff
Mesmo com throttling, pode acontecer de algumas requisições serem rejeitadas se o limite for ultrapassado. Para tratar esses casos:
3.1 Backoff Exponencial
Quando o serviço retornar 429 Too Many Requests ou outro erro temporário, aplique exponential backoff (ex.: esperar 1s, depois 2s, 4s, 8s etc.) antes de tentar novamente.
- Vantagem: Evita bombardear o serviço em períodos de instabilidade.
- Desvantagem: Se exagerado, aumenta a latência da resposta ao usuário.
3.2 Cabeçalho Retry-After
Alguns serviços retornam cabeçalhos como Retry-After ou X-RateLimit-Reset. Leia essa informação para saber quando você pode fazer uma nova requisição de forma segura. Assim, seu backoff pode se basear nessas dicas em vez de ser puramente exponencial.
3.3 Circuit Breaker
Se o serviço estiver consistentemente rejeitando requisições por limite atingido, talvez seja melhor abrir o “circuito” por um tempo — ou seja, parar de enviar requisições temporariamente. Esse padrão se chama Circuit Breaker e impede que você desperdice recursos com tentativas contínuas que falharão.
4. Fila e Processamento Assíncrono
Nem toda integração precisa ser síncrona (request-response). Se for aceitável para o negócio processar dados em lotes ou de forma escalonada:
- Fila de Mensagens
- Enfileire requisições em um sistema como RabbitMQ, Kafka ou SQS.
- A partir daí, um “worker” consome as requisições respeitando o limite configurado.
- Batch Processing
- Em vez de enviar requisições isoladas, agrupe dados e envie em lotes (se a API suportar).
- Reduz o overhead de chamadas e pode ajudar a contornar limites por requisição.
Essa abordagem gera um desacoplamento: sua aplicação não fica bloqueada esperando a resposta imediata, mas, em contrapartida, o resultado chega de forma retardada.
5. Monitoramento e Observabilidade
Para evitar surpresas, você precisa monitorar quantas requisições está fazendo, qual a taxa de sucesso/falha e se está recebendo muitos status 429.
- Logs Centralizados
Registre todas as tentativas e respostas. Assim, você consegue identificar picos de volume e quais endpoints mais consomem o rate limit. - Métricas (Prometheus, Grafana, etc.)
Colete métricas como:- Taxa de requisições/segundo
- Taxa de erros (429, 5xx)
- Tempo médio de resposta
- Alertas
Configure alertas para quando a taxa de erro ultrapassar um limiar. Dessa forma, você pode reagir rapidamente a uma sobrecarga.
6. Cache de Respostas
Dependendo do tipo de requisição, cachear os resultados pode ser uma forma de reduzir drasticamente o número de chamadas. Se você está consultando o mesmo dado repetidamente e ele não muda com frequência, um cache local ou distribuído (Redis, Memcached) pode aliviar a pressão no serviço externo.
- Importante: Verifique se as informações retornadas pela API podem ser armazenadas em cache (aspectos de privacidade e consistência).
- Validade: Defina regras de expiração ou invalidação do cache conforme as necessidades do negócio.
7. Boas Práticas de Arquitetura
7.1 Estrangular o Acesso em um Ponto Central
Concentre as chamadas à API de terceiros em um serviço ou módulo dedicado. Dessa forma, fica mais fácil aplicar a lógica de rate limit, cache e retentativa em um único lugar.
7.2 Escalonamento Horizontal
Se o seu sistema roda em múltiplas instâncias, sincronize o estado de throttling para que cada instância não exceda o limite individualmente, resultando em um total muito acima do permitido. Uma abordagem é usar um repositório compartilhado (Redis, por exemplo) para controlar contadores de requisições.
7.3 Políticas de Requisições Prioritárias
Em determinados cenários, algumas requisições podem ter maior prioridade. Ajuste sua estratégia de throttling para garantir que requisições críticas sejam atendidas primeiro, enquanto requisições de baixa prioridade podem sofrer espera maior.
8. Exemplo de Implementação Simples (Pseudo-Go)
A seguir um exemplo simplificado usando um token bucket em Go. Não é uma solução de produção, mas ilustra o conceito:
package main
import (
"fmt"
"sync"
"time"
)
type RateLimiter struct {
tokens int
maxTokens int
refillRate int // tokens por intervalo
refillPeriod time.Duration
mu sync.Mutex
}
func NewRateLimiter(maxTokens, refillRate int, refillPeriod time.Duration) *RateLimiter {
rl := &RateLimiter{
tokens: maxTokens,
maxTokens: maxTokens,
refillRate: refillRate,
refillPeriod: refillPeriod,
}
go rl.refill() // Goroutine para reabastecer tokens
return rl
}
func (rl *RateLimiter) refill() {
ticker := time.NewTicker(rl.refillPeriod)
defer ticker.Stop()
for range ticker.C {
rl.mu.Lock()
rl.tokens += rl.refillRate
if rl.tokens > rl.maxTokens {
rl.tokens = rl.maxTokens
}
rl.mu.Unlock()
}
}
func (rl *RateLimiter) AllowRequest() bool {
rl.mu.Lock()
defer rl.mu.Unlock()
if rl.tokens > 0 {
rl.tokens--
return true
}
return false
}
func main() {
// Exemplo: 10 tokens iniciais, reabastece 5 tokens a cada 2 segundos
rl := NewRateLimiter(10, 5, 2*time.Second)
// Simulação de requisições
for i := 0; i < 20; i++ {
if rl.AllowRequest() {
fmt.Printf("Requisição %d permitida.\n", i)
} else {
fmt.Printf("Requisição %d bloqueada (excedeu rate limit).\n", i)
}
time.Sleep(300 * time.Millisecond)
}
}
- tokens: quantos recursos há disponíveis para novas requisições.
- refill(): repõe os tokens de forma periódica.
- AllowRequest(): verifica se ainda há tokens para liberar a requisição.
Essa lógica pode ser complementada com um sistema de filas ou retentativas caso a requisição não seja permitida no momento.
9. Conclusão
Lidar com rate limits exige planejamento e técnicas de controle de fluxo que evitem sobrecarregar o serviço externo e, ao mesmo tempo, garantam uma boa experiência para seus usuários. Ao implementar mecanismos de throttling, backoff, cache e monitoramento, você não só evita erros de “Too Many Requests” como também constrói uma aplicação mais resiliente e escalável.
Quais estratégias você tem adotado para lidar com rate limits em suas integrações? Deixe seus comentários e compartilhe suas dicas!