Por que retries ingênuos pioram uma queda, e como você desenharia uma política de retry segura?

Retries ingênuos multiplicam carga exatamente quando um serviço já está sofrendo, e clientes sincronizados repetem em ondas coordenadas. Use backoff exponencial com full jitter, limite o total de tentativas, e só repita operações idempotentes em erros repetíveis. Acrescente um orçamento de retry no cliente para que retries fiquem numa fração pequena do tráfego, mais um circuit breaker para parar as chamadas de vez quando a taxa de falha dispara. Nunca faça retry de forma independente em cada camada da pilha.

O problema é que retries são carga extra aplicada no pior momento possível. Se um serviço está falhando a 50% e cada cliente tenta três vezes, você acabou de triplicar o tráfego batendo em algo que já está acima da capacidade, e ele nunca ganha chance de se recuperar. Backoff exponencial puro também não basta, porque todos os seus clientes falharam no mesmo instante, então todos acordam no mesmo instante. Full jitter resolve isso, então o sleep é um valor aleatório entre zero e o teto atual do backoff. Além disso eu só faria retry de chamadas idempotentes, só em 503, 429 e erros no nível de conexão, nunca num 400, e eu imporia um orçamento de retry para que retries fiquem limitados a algo como 10% do total de requisições. A que nos pegou foi o empilhamento. O SDK tentava três vezes, o mesh tentava duas, e o executor de jobs tentava de novo, o que dá dezoito tentativas para uma chamada lógica.