Retries e Amplificação de Retry no Istio

Os retries são definidos na rota do VirtualService com `retries.attempts`, `retries.perTryTimeout` e `retries.retryOn`. O campo `retryOn` é o mais importante: ele controla quais falhas são reprocessadas. Valores comuns são `5xx`, `reset`, `connect-failure` e `gateway-error`. Nunca coloque `retriable-4xx` em endpoints POST a menos que você saiba que eles são idempotentes. O grande perigo é a amplificação de retry em um grafo de chamadas profundo. Se o gateway tenta 3 vezes, e o próximo salto tenta 3 vezes, e o salto seguinte tenta 3 vezes, uma única requisição de usuário pode gerar 27 chamadas de backend. Quando o downstream já está com dificuldades, esses retries são exatamente o que o empurra de lento para morto. A correção é fazer retry só na borda ou só uma vez nos saltos internos, e definir um `perTryTimeout` apertado para que o tempo total fique limitado. Combine retries com circuit breakers no DestinationRule, para que, assim que um host começa a falhar, você pare de acioná-lo em vez de continuar tentando dentro do incêndio. E garanta que `attempts` mais `perTryTimeout` não ultrapasse o `timeout` geral da rota — se ultrapassar, o timeout dispara antes que os retries terminem e você desperdiça o orçamento de tempo.