Cenários de Falha e Recuperação

O problema

Muita arquitetura fala de disponibilidade como se o sistema fosse elegante demais para falhar.

Quando a dependência cai de verdade, a reação vira improviso:

• retry infinito
• timeout gigante
• restart e esperança

Isso não é resiliência.

É desespero com nome técnico.

Modelo mental

Falha faz parte do sistema.

Pensar em recuperação direito é responder quatro perguntas:

1. o que quebrou
2. quem depende disso
3. o que pode degradar e o que precisa parar
4. como o sistema volta para um estado coerente

Se você responde isso cedo, o desenho deixa de parecer slogan e começa a parecer operação real.

Quebrando o problema

Nomeie a falha de forma concreta

“O sistema caiu” quase nunca ajuda.

Ajuda mais dizer algo como:

• o banco ficou indisponível
• o gateway de pagamento está lento
• o broker está atrasando entrega
• o storage não aceita escrita

Quando a falha fica concreta, o resto da análise melhora.

Separe o que para do que degrada

Nem toda falha precisa virar erro total.

Às vezes existe modo degradado aceitável.

Mas isso precisa ser explícito.

Exemplos:

• leitura continua, escrita para
• pedido entra como pendente
• relatório demora mais, mas não some

Trate retry como ferramenta perigosa

Retry ajuda em falha transitória.

Mas retry sem limite pode:

• aumentar fila
• saturar dependência já ruim
• duplicar efeito colateral

Por isso, retry bom costuma vir com:

• limite
• backoff
• idempotência
• fila ou quarentena quando necessário

Também precisa de critério para parar.

Se o sistema não sabe quando desistir, ele só transforma uma falha localizada em incidente espalhado.

Recuperar é voltar para estado confiável

Esse ponto separa muita resposta superficial de resposta madura.

Recuperar não é só voltar a responder.

É voltar sem deixar:

• pagamento duplicado
• pedido órfão
• status mentiroso
• reprocessamento confuso

Exemplo simples

Imagine uma API de pedidos que depende de um gateway de pagamento.

Se o gateway cair, você pode escolher:

• bloquear novas compras
• aceitar pedido e marcar pagamento como PENDING
• aceitar com limite e reprocessar tentativa depois

Cada escolha tem custo.

Bloquear tudo protege consistência, mas derruba conversão.

Aceitar pedido pendente preserva fluxo, mas cria passivo operacional e expectativa no usuário.

Uma resposta madura poderia soar assim:

Se o gateway falhar, eu não vou fingir normalidade. Posso aceitar o pedido em estado pendente, com tempo limite claro, e reprocessar tentativa de pagamento em fila. Também preciso impedir retry sem limite e ter reconciliação para limpar pendências antigas.

Agora a resposta não fala só de falha.

Fala de:

• comportamento durante a falha
• experiência do usuário
• volta para consistência
• custo da decisão durante a recuperação

Erros comuns

• Falar de retry sem limite.
• Chamar qualquer fallback de resiliência.
• Ignorar o estado do usuário durante a falha.
• Recuperar disponibilidade e esquecer consistência.
• Tratar falha como detalhe operacional separado do produto.

Como um senior pensa

Quem tem mais experiência costuma trocar a pergunta “como evitar falha?” por outra mais útil:

Quando isso quebrar, o que eu quero que o sistema faça de forma explícita?

Essa pergunta é forte porque obriga você a definir:

• modo degradado
• visibilidade para o usuário
• limite de tentativa
• limpeza de estado

O que o entrevistador quer ver

Em entrevista, falha e recuperação servem para medir maturidade operacional.

O entrevistador quer ver se você:

• trata falha como parte do fluxo
• define degradação aceitável
• pensa em retry com limite
• cuida da volta para estado consistente

Arquitetura madura não promete que nada quebra. Ela decide antes o que fazer quando quebrar.

Recuperação de verdade não é restart. É retorno controlado para um estado em que o sistema volta a merecer confiança.