1
resposta

Muito se falou sobre a limitação de requisições e foi até proposto no curso o uso de um limite de 50/20 requisições por dia.
Porém, não é preciso ser um profissional sênior em tecnologia para perceber que esse tipo de limitação não é muito funcional, já que um usuário pode facilmente acessar um site ou uma API mais de 50 vezes em um único dia.

Diante disso, surge minha dúvida: como definir um número mais realista e tecnicamente honesto para esse tipo de limitação?
No meu entendimento, faria mais sentido trabalhar com limites por minuto ou por segundo, em vez de por dia.

Sei que a resposta pode envolver fatores como capacidade do servidor, infraestrutura, volume de usuários, etc., mas o foco da minha dúvida não é esse. O que eu gostaria de entender é a lógica por trás da definição desses limites e como isso é pensado na prática.

1 resposta

A definição técnica de limites ignora contadores fixos para focar no comportamento de vazão (throughput). Em vez de uma cota diária, utiliza-se a lógica de janelas granulares (segundos ou minutos) e algoritmos como o Token Bucket, que permite picos de uso (bursts) para carregamento de páginas, mas restringe a taxa média de consumo. Isso garante que um usuário legítimo navegue sem interrupções, enquanto processos automatizados são contidos pela taxa de regeneração de tokens.
Na prática, o número "realista" é derivado da observabilidade, utilizando o percentil 99 (P99) do tráfego real para estabelecer um teto que não penalize o comportamento humano. A implementação é delegada a camadas de Middleware no Redis ou API Gateways, segmentando limites por peso computacional: endpoints que consomem muita IOPS de banco de dados possuem limites restritos, enquanto consultas leves em cache permitem volumes significativamente maiores.