Degradação graciosa: funcionar pela metade é melhor que sair do ar

Nenhum sistema está imune a falhas: um serviço externo cai, o banco fica lento, uma funcionalidade nova tem um bug. A diferença entre sistemas frágeis e resilientes não é falhar menos — é falhar melhor.

O que é

Projetar o sistema para que, quando uma parte falha, o restante continue funcionando com uma versão reduzida da experiência, em vez de exibir uma tela de erro geral.

Exemplos

• Recomendações fora do ar: a página do produto mostra os mais vendidos.
• Cálculo de frete indisponível: o checkout segue e o frete é confirmado depois.
• Chat com IA fora: botão de WhatsApp com atendimento humano.
• Mapa não carrega: endereço em texto com link para abrir no aplicativo de mapas.
• API lenta no app: dados em cache com aviso de "última atualização" (Offline-first: apps que continuam funcionando sem internet).

Como planejar

1. 1.Liste as dependências de cada tela e o que acontece se cada uma falhar.
2. 2.Defina o essencial: o que precisa funcionar de qualquer jeito (login, checkout, contato).
3. 3.Isole as falhas: um componente com erro não pode derrubar a página inteira.
4. 4.Timeouts e circuit breakers para não esperar serviços mortos (Timeouts: a configuração esquecida que derruba sistemas, Circuit breaker: quando um serviço externo cai, o seu não precisa cair junto).
5. 5.Mensagens honestas para o usuário (Estados vazios e de erro: as telas que ninguém desenha (e todo usuário vê)).

Teste a falha

Desligue propositalmente uma dependência em homologação e veja o que acontece. É a forma mais confiável de saber.

A We Codex constrói sistemas resilientes. Veja sistemas web ou fale com a gente.