Timeout, retry e deadline sem deixar cada camada decidir sozinha

O problema

Muita discussão sobre resiliência vira catálogo de knobs:

• timeout
• retry
• backoff
• breaker
• deadline

Só que, em bastante time, cada pedaço do sistema decide isso sozinho.

Resultado:

• client HTTP com timeout de 10s
• SDK do provider com retry interno
• use case repetindo de novo
• worker sem deadline nenhum

No papel, parece proteção.

Na prática, vira um sistema que espera demais, repete demais e ninguém entende direito por quê.

Modelo mental

Vale separar três coisas:

• timeout: quanto uma chamada individual pode esperar
• retry: quando vale tentar de novo depois de falha
• deadline: quanto tempo o fluxo inteiro ainda pode gastar

Essa distinção importa porque timeout local não controla o fluxo inteiro.

Sem deadline, é fácil cada chamada “usar um pouquinho” até o request inteiro virar uma espera longa e boba.

Onde o desenho costuma quebrar

O desenho quebra quando o time empilha política sem perceber:

• request web já faz retry
• biblioteca também faz retry
• fila reenfileira depois
• operação não é idempotente

Agora uma única falha transitória pode virar:

• 3 tentativas locais
• 2 tentativas na biblioteca
• 5 reprocessamentos no worker

Não é resiliência.

É multiplicação de risco.

Exemplo simples

Imagine um fluxo de checkout que precisa:

• validar risco
• autorizar pagamento
• registrar pedido

Se o request inteiro tem orçamento de 2 segundos, não faz sentido cada integração agir como se tivesse 2 segundos próprios.

Uma leitura melhor é:

• deadline total do fluxo: 2s
• risco pode gastar até X
• pagamento pode gastar até Y
• se o orçamento restante ficar pequeno demais, o sistema para de insistir

Isso evita o clássico request que ainda está “tentando ser resiliente” quando o usuário já foi embora.

Retry não é obrigação moral

Retry faz sentido quando:

• a falha é transitória
• a operação é segura para repetir
• o custo de insistir ainda cabe no fluxo

Retry faz menos sentido quando:

• a falha é claramente permanente
• a operação não é idempotente
• a latência adicional destrói a experiência
• o fluxo já perdeu o tempo útil

Tem time que trata retry como reflexo automático.

Isso costuma esconder decisão ruim.

Onde essa política deveria morar

Normalmente, a política deveria ser definida perto da orquestração do fluxo ou em cliente compartilhado bem controlado.

Não espalhada em:

• helper isolado
• SDK com defaults esquecidos
• chamada aleatória no meio do use case

O sistema precisa ter uma ideia coerente de:

• quanto tempo ainda resta
• quais erros merecem nova tentativa
• onde a insistência para

Como um senior pensa

Quem tem mais julgamento costuma perguntar:

• qual é o orçamento real deste fluxo?
• se isso falhar, insistir melhora ou piora?
• em que camada o retry deve existir para não duplicar política?
• a operação aguenta repetição legítima?

Essa conversa é muito melhor do que “vamos aumentar timeout”.

Ângulo de entrevista

Esse tema aparece em backend, integração externa, incidentes e system design.

O entrevistador quer ver se você entende:

• que timeout local e deadline global não são a mesma coisa
• que retry sem idempotência pode piorar a falha
• que política espalhada torna o comportamento imprevisível

Resposta forte costuma soar assim:

“Eu trataria timeout, retry e deadline como política de fluxo. Definiria onde o retry realmente mora, propagaria o orçamento de tempo do request e só repetiria o que for transitório e seguro para executar de novo.”

Takeaway direto

Sistema resiliente não é o que tenta para sempre.

É o que insiste com critério e desiste no momento certo.