Um checklist de degradação graciosa para times de produto

A maioria das quedas não é total. O banco está lento, não fora do ar. O serviço de recomendações está dando timeout. O provedor de pagamento responde em oito segundos em vez de um. O que o usuário vê nesses momentos é uma decisão de produto, e ela normalmente é tomada por acidente, por qualquer caminho de erro que um desenvolvedor escreveu primeiro.

Degradação graciosa é escolher de propósito. Este é o checklist que percorro com times de produto, idealmente antes do primeiro incidente, e na prática depois dele.

Decida o que é essencial

Comece separando funcionalidades em essenciais e opcionais. Essencial é o que o usuário veio fazer: ver o catálogo, fechar a compra, ler as mensagens. Opcional é tudo que melhora isso: recomendações, ordenação personalizada, estoque em tempo real, avaliações, o widget de chat. A regra é que uma funcionalidade opcional falhando nunca pode derrubar uma essencial. Parece óbvio e é violado o tempo todo: uma chamada de recomendações na página de produto sem timeout, travando a renderização do próprio produto.

Depois de separar, cada funcionalidade opcional precisa de um fallback que um designer já viu. Um espaço vazio, uma lista genérica, uma seção 'populares agora' servida de um cache estático. Seja o que for, não é um spinner e não é um erro.

O checklist

• Recomendações fora: mostre uma lista curada ou em cache, ou esconda o bloco. Nunca bloqueie a página.
• Busca fora: caia para navegação por categoria e uma query mais simples no banco. Diga 'a busca está limitada agora' em vez de mostrar zero resultados.
• Pagamento lento: mostre o progresso com honestidade, mantenha o botão desabilitado e nunca deixe um duplo clique gerar duas cobranças. Tenha um limite a partir do qual você diz ao usuário para aguardar a confirmação por e-mail.
• Pagamento fora: aceite o pedido em estado pendente se o negócio permitir, e confirme depois. Se não permitir, diga com clareza e preserve o carrinho.
• Réplica de leitura atrasada: rotule o dado com 'atualizado em' e um horário em vez de fingir que é ao vivo.
• Banco principal fora ou em failover: entre em modo somente leitura. O usuário navega, não compra, e sabe o porquê.
• Qualquer escrita falhando: enfileire a escrita, confirme ao usuário que foi recebida e processe quando a dependência voltar. Só é aceitável se 'recebido' e 'concluído' forem estados diferentes na interface.
• Analytics ou tracking de terceiros fora: o produto não pode perceber. Dispare e esqueça, com timeout curto.
• Feature flags: toda funcionalidade opcional tem um kill switch que vira sem deploy, e quem está de plantão sabe onde ele fica.

Velho é melhor que ausente, se tiver rótulo

Existe uma tentação forte de esconder tudo que não é fresco. Resista. O estoque de ontem com rótulo é mais útil que um erro, desde que o usuário consiga ver a diferença. O modo de falha a evitar é dado velho apresentado como ao vivo: um item esgotado mostrado como disponível, uma fatura paga mostrada como em aberto. O rótulo é o que torna a defasagem honesta. 'Atualizado há 14 minutos' não custa nada e evita um chamado no suporte.

O mesmo vale para escritas enfileiradas. 'Recebemos seu pedido e vamos confirmar por e-mail' está ok. 'Seu pedido está confirmado' quando ele está parado numa fila de retry não está. Combine as palavras com o estado.

Modo somente leitura é funcionalidade, construa

O modo somente leitura é o modo de degradação mais valioso e o menos construído. Precisa de uma flag global, um middleware que rejeita escritas com mensagem clara e uma interface que esconde ou desabilita ações de escrita em vez de deixar o usuário preencher um formulário e falhar no final. Construa numa semana tranquila. Durante um failover de banco, ele transforma uma queda completa num incômodo leve.

Pratique

Nada disso funciona se a primeira vez que você vira a chave for durante o incidente. Desligue as recomendações numa terça à tarde e olhe a página. Coloque o sistema em somente leitura por dez minutos em staging com a interface real. Derrube o provedor de pagamento no sandbox e veja o que um duplo clique faz. Times de produto que já viram seus estados degradados ficam calmos em incidentes. Os que não viram descobrem como o produto fica ao mesmo tempo que os usuários.