Resiliência: o que acontece quando algo falha?
Em muitos projetos paira a crença: "Aqui não pode falhar." Sistemas falham, serviços caem, redes oscilam, integrações quebram. A pergunta não é se vai falhar, é quando. Se você é BA e desenha fluxos só pro cenário ideal, está escrevendo metade da história. Produto maduro não é o que nunca falha; é o que sabe como falhar. Isso tem nome: resiliência.
É a capacidade do sistema continuar funcionando quando partes dele falham. Não é ausência de falha; é tolerância à falha. Você abre um app, uma parte da tela carrega e outra mostra: "Não foi possível carregar no momento." O app continua utilizável. Isso é resiliência. Agora imagina o app fechando ou mostrando erro genérico. Você escreve: "Ao clicar em confirmar, processar pagamento, atualizar estoque e enviar e-mail." E se o gateway de pagamento estiver fora? E se o serviço de estoque estiver lento, o de e-mail fora do ar? Se você não define o comportamento sob falha, alguém decide por padrão técnico — e padrão técnico nem sempre considera experiência.
Fluxo de compra: criar pedido, processar pagamento, reservar estoque, emitir nota, enviar notificação. Se qualquer etapa falhar, o que acontece? Sem resiliência você pode ter pagamento confirmado sem estoque reservado, pedido criado sem pagamento — e o problema vira reconciliação manual. Falha catastrófica: sistema trava, tela congela, dados inconsistentes. Falha controlada: sistema identifica o problema, faz rollback, mostra mensagem clara, permite tentar de novo. Quando um sistema chama outro, existe um tempo máximo de espera — o timeout. Quanto tempo o usuário deve esperar? Se você não define, o sistema pode esperar indefinidamente ou criar frustração. Timeout não é só configuração; é decisão de experiência.
"Antes de aprovar pedido, validar score antifraude." E se o serviço estiver fora do ar? Bloquear todas as vendas? Aprovar sem validação? Colocar em análise manual? Cada decisão tem impacto financeiro. Sistemas resilientes não param de uma vez; degradam. Se o serviço de recomendação falhar, o sistema pode mostrar produtos padrão — mas não deve impedir a compra. Essa dependência precisa bloquear o usuário? O e-mail de confirmação precisa ser enviado antes de liberar a tela de sucesso? Provavelmente não; pode ser assíncrono. Quanto mais integrações externas, maior o risco. Parceiro pode ficar indisponível, mudar contrato. Vale perguntar: tem plano B? Fallback? Retentativa? Black Friday: volume sobe e o serviço de pagamento sobrecarrega. Se seu fluxo espera confirmação síncrona sem timeout definido, o resultado é tela travada, usuário clicando de novo, duplicidade.
Antes de fechar fluxo crítico: o que acontece se o serviço A falhar? E se o B demorar? E se a rede oscilar? Quando a falha acontece, a experiência precisa ser clara. Mensagem genérica: "Erro inesperado." Mensagem resiliente: "Não conseguimos processar seu pagamento agora. Nenhuma cobrança foi feita. Tente em alguns minutos." Você não implementa retry, mas pode exigir comportamento sob falha. Frágil: funciona quando tudo está perfeito, quebra sob pressão. Confiável: se adapta quando algo falha, mantém integridade, comunica claro.
Sistemas falham, rede falha, pico acontece. Isso é inevitável. O que não é inevitável é o despreparo. Maturidade não é evitar erro — é saber reagir a ele.
No próximo e último post da série: um checklist prático — as perguntas que mudam sua atuação como BA.
