Retry não é resiliência

Um retry resolve apenas uma classe estreita de problema: uma falha realmente transitória, com chance razoável de a próxima tentativa encontrar um sistema saudável. Fora desse cenário, ele só troca um erro explícito por mais carga, mais latência e menos clareza durante um incidente.

Pense em uma API que já está saturada. Se cada requisição que recebe timeout gera três novas tentativas imediatamente, a dependência recebe mais trabalho justamente quando tem menos capacidade para responder. O efeito pode se espalhar por toda a cadeia de chamadas. Isso é um retry storm.

Antes de repetir, defina o orçamento

O timeout da chamada precisa caber no tempo total disponível para atender quem iniciou a requisição. Se a operação inteira tem 800 ms, não é coerente tentar três chamadas de 500 ms em sequência. O orçamento deve incluir fila, serialização, rede, processamento e uma margem para devolver uma resposta útil.

Também é preciso classificar o erro:

• erro de validação ou autorização não deve ser repetido;
• 404 normalmente não melhora na próxima tentativa;
• rate limit pode pedir espera explícita;
• conexão recusada ou 503 podem ser transitórios, mas precisam de limite;
• um timeout é ambíguo: a operação pode ter sido concluída, mesmo sem resposta.

Esse último caso conecta retry e idempotência. Repetir um pagamento, envio de e-mail ou publicação de evento sem uma chave idempotente pode duplicar efeitos no mundo real.

O conjunto mínimo que torna retry seguro

Um retry útil costuma vir acompanhado de quatro decisões:

1. Limite de tentativas. Poucas, com motivo explícito.
2. Backoff exponencial com jitter. As tentativas se espalham no tempo, evitando que muitos clientes voltem juntos.
3. Limite de concorrência. Protege tanto quem chama quanto quem recebe.
4. Circuit breaker ou fallback. Quando a dependência está consistentemente indisponível, pare de insistir e devolva uma degradação conhecida.

Nada disso elimina a falha. O objetivo é impedir que ela se transforme em uma falha maior e mais difícil de recuperar.

Observe a política, não só o erro final

Uma métrica de erro pode continuar baixa enquanto o sistema gasta boa parte do tempo refazendo trabalho. Acompanhe pelo menos a taxa de tentativas, tempo por dependência, operações esgotadas, circuitos abertos e o percentual de respostas degradadas. Sem isso, o retry vira uma decisão invisível de capacidade.

Resiliência é saber como o sistema se comporta quando algo dá errado. Retry é apenas uma das ferramentas possíveis nesse desenho.