Cenarios reais / Cenarios de falha e recuperacao
Cenarios de falha e recuperacao
Cenarios de Falha e Recuperacao
Como pensar em sistema real quando alguma parte quebra, sem tratar resiliência como slogan.
O problema
Muita arquitetura fala muito de disponibilidade e pouco de comportamento sob falha.
Quando uma dependência cai, a resposta vira improviso: retry cego, timeout maior, restart e esperança.
Isso até pode aliviar o momento, mas não descreve recuperação de verdade.
Modelo mental
Falha faz parte do sistema, não exceção filosófica.
A pergunta útil aqui costuma ser:
Quando essa parte quebrar, o que deve parar, o que pode degradar e como o sistema volta ao normal?
Isso muda a conversa de “evitar falha” para “tratar falha com critério”.
Quebrando o problema
Uma forma simples de estruturar esse cenário é esta:
- diga qual componente falha
- defina quem depende dele
- escolha a degradação aceitável
- explique recuperação, retry ou compensação com limite claro
Isso transforma resiliência em decisão observável.
Exemplo simples
Imagine uma API de pedidos que depende de um serviço de pagamento.
Se o pagamento cai, algumas opções existem:
- bloquear tudo
- aceitar pedido e deixar pagamento pendente
- enfileirar tentativa posterior com status explícito
A melhor resposta depende do negócio, mas o importante é deixar claro o comportamento.
Erros comuns
- falar de retry sem limite
- tratar fallback como se fosse sempre seguro
- esquecer consistência depois da recuperação
- descrever alta disponibilidade sem explicar o que acontece quando a falha chega
Como um senior pensa
Um senior forte não para na palavra resiliência.
Ele define comportamento concreto.
Normalmente isso soa assim:
Se esse componente falhar, eu não quero que o sistema finja normalidade. Eu quero um modo degradado explícito e uma recuperação que não duplique trabalho nem esconda estado inconsistente.
O que o entrevistador quer ver
Em entrevista, isso costuma mostrar maturidade rápido:
- você pensa em falha como fluxo do sistema
- você sabe definir degradação aceitável
- você considera recuperação e consistência juntos
Quem faz isso bem parece alguém preparado para ambiente real, não só para happy path bem explicado.
Sistema maduro não ignora falha. Ele decide como falhar.
Se a recuperação não está clara, a arquitetura ainda está otimista demais.