Rate limit

Pensa no garçom numa noite lotada. Ele dá conta do salão inteiro, desde que ninguém monopolize. Se uma mesa chama sem parar, ele diz espera um pouco e segue atendendo as outras.

Esse limite não é castigo, é o que mantém o restaurante de pé pra todo mundo. Sem ele, basta um cliente afobado chamando o garçom sem parar pra derrubar o atendimento do salão inteiro, e todas as outras mesas ficam sem ser servidas. É por isso que toda API séria tem um rate limit: ele protege o sistema, não só incomoda quem está pedindo.

Você já viu isso quando o WhatsApp Web trava depois de você mandar mensagem rápido demais pra muita gente em sequência, ou quando uma ferramenta de automação para no meio do trabalho com um aviso de "muitas requisições, tente de novo mais tarde". Não é bug, é o sistema protegendo a própria cozinha.

No meu site, a API do YouTube tem uma cota diária, e eu já esbarrei nela. A solução foi ter um plano B: quando a cota estoura, o site passa a ler o feed público do canal em vez de chamar a API, e assim a página de vídeos nunca fica vazia pro visitante.

A ressalva é que o limite quase nunca é o mesmo pra todo mundo. Quem paga mais costuma ter uma cota maior, e um app gratuito às vezes esbarra num teto bem mais baixo do que você imagina, mesmo fazendo pouca coisa.

Mas a ideia central fica: rate limit não existe pra te atrapalhar, existe pra ninguém derrubar o restaurante inteiro.

O próximo termo é timeout: o momento em que o sistema desiste de esperar o pedido chegar.