Rate Limiting: Quando Proteger a API É Proteger Você Mesmo

Mais uma das coisas que relato aqui e viram aprendizado.Esqueci um script rodando num cron de teste.

Era integração simples: bater num endpoint a cada minuto, puxar cotação, salvar no banco. Só que eu tinha deixado o intervalo errado em staging. Não era um minuto. Era um segundo. Milhares de requests em poucos minutos.

A API não caiu de vez. Ficou lenta o bastante pra parecer que o banco tinha morrido. O RabbitMQ do projeto de faculdade já tinha me mostrado sintoma parecido: produtor rápido demais, consumer não acompanha, fila enche, memória sobe, tudo trava.

Mesma doença, nomes diferentes.

Rate limit costuma aparecer como proteção contra ataque ou cliente mal configurado. Também é proteção contra você mesmo.

Limite de requests por IP ou por token força ritmo. Quem passa recebe 429 Too Many Requests e idealmente um header Retry-After dizendo quando tentar de novo.

Sem isso, cada request vira trabalho completo: auth, query, serialização, log. Cem por segundo parece pouco até multiplicar pelo custo de cada um.

Existem algoritmos com nome assustador. Na prática eu penso em balde de fichas.

O balde enche até um máximo. Cada request gasta uma ficha. Acabou ficha, espera ou leva 429. Com o tempo, fichas voltam numa taxa fixa.

Token bucket permite rajada curta se sobrou ficha acumulada. Bom pra tráfego irregular legítimo.

Sliding window conta requests numa janela móvel de tempo. Mais preciso, mais chato de implementar. Pra maioria dos casos, bucket resolve.

Não precisa reinventar. Nginx, API gateway, Redis com script Lua, middleware no framework. O importante é ter limite explícito antes do controller.

No projeto com RabbitMQ, rate limit na API não bastava se o consumer processava devagar.

Fila crescendo é sinal de backpressure. O produtor precisa desacelerar ou o sistema precisa escalar consumer. Só jogar mensagem na fila sem olhar profundidade é acumular dívida.

Configurei prefetch baixo e monitorando tamanho da fila. Quando passava de threshold, pausava publicação. Feio? Sim. Funcional? Talvez.

Instinto errado: API lenta, sobe mais instância.

Se o gargalo é query sem índice ou fila sem consumer, instância nova só multiplica o problema. Rate limit expõe o gargalo cedo. Você vê 429 subir e investiga antes de pagar conta de cloud maior.

Scripts de integração agora têm sleep explícito e limite de retry. Endpoints públicos têm rate limit por token. Filas têm alerta de profundidade.

Proteger a API virou proteger o sono. Quem desenvolve backend devia aprender isso cedo, antes do primeiro cron esquecido em staging.

Fora isso… Obrgiado pela atenção, um abraço e até mais!

j