Resiliência e timeouts
TLDR
Resiliência aqui é: quando um sistema do qual a jornada depende está lento ou caiu, o que acontece? O usuário fica esperando para sempre? Aparece uma mensagem de erro depois de quanto tempo? Esse “tempo máximo de espera” (timeout) e o que fazer depois (mensagem alternativa, “tente novamente”) são decisão de produto tanto quanto técnica. Quem desenha ou prioriza produto pode perguntar: o que o usuário vê se esse sistema demorar ou falhar?
Por que isso importa
Definir mensagens e experiência quando algo falha ou demora não é só “coisa de engenharia” — é decisão de produto. Evitar prometer “sempre rápido” em jornadas que dependem de vários sistemas reduz frustração e expectativa errada.
Conceito (em linguagem simples)
- Timeout: Tempo máximo que a gente espera uma resposta antes de considerar que “não veio” e mostrar outra coisa (erro, “tente novamente”, valor em cache).
- Fallback: O que mostrar ou fazer quando o sistema não responde (ex.: “serviço temporariamente indisponível”, “tente em alguns minutos”).
Vale perguntar: o que o usuário vê se esse sistema falhar ou demorar? Qual o tempo máximo de espera que consideramos aceitável?
Conclusão
Timeout e comportamento em falha são decisão de produto; alinhar com engenharia evita experiência ruim e expectativa errada com o usuário.