Quando uma aplicação depende de serviços internos ou externos, a falha de um deles não deveria obrigar automaticamente a interromper tudo. Porém, manter todas as funções como se nada estivesse acontecendo também pode gerar dados inconsistentes, operações duplicadas ou decisões baseadas em informações desatualizadas. Projetar a degradação controlada significa decidir com antecedência quais recursos continuarão disponíveis, quais serão limitados e quais deverão ser bloqueados enquanto uma dependência não responder.
A decisão deve proteger o processo de negócio, e não apenas a disponibilidade técnica. Para cada função, é importante considerar de qual serviço ela precisa, o que acontece se ele faltar, por quanto tempo a interrupção é tolerável e como a consistência será restabelecida depois. Assim, a equipe pode oferecer uma alternativa útil sem esconder o problema nem assumir riscos desnecessários.
O que significa degradar de forma controlada
Uma aplicação está em degradação controlada quando, diante de uma falha ou resposta insuficiente de uma dependência, mantém um conjunto deliberado de funções com limites explícitos. Não se trata de uma cópia completa do serviço nem de uma promessa de que tudo continuará funcionando. É uma política de comportamento para situações de falha parcial.
Esse conceito se diferencia de outros mecanismos relacionados:
- Modo offline: permite usar determinadas funções sem conectividade e, em alguns casos, sincronizar alterações posteriormente. A degradação controlada também pode ser aplicada quando há rede, mas um serviço específico falha.
- Novas tentativas: repetem uma solicitação que falhou, normalmente com limites e intervalos. Por si só, não resolvem o que a pessoa deve ver ou fazer enquanto a dependência continuar indisponível.
- Degradação controlada: define a experiência e as regras de negócio durante a falha, incluindo quais operações são permitidas, com quais dados e sob quais restrições.
Por exemplo, se um serviço de recomendações falhar, a aplicação poderá exibir uma seleção genérica e manter a busca disponível. Se falhar a validação necessária para confirmar um pagamento, permitir a cobrança mesmo assim pode criar um risco maior do que interromper temporariamente essa ação.
Relacione cada função às dependências e aos impactos
Comece por um mapa dos recursos do produto, e não por um inventário isolado de serviços. Para cada função visível, registre de quais dependências ela precisa e qual resultado produz. Uma ficha útil inclui a operação, o serviço necessário, os dados lidos ou gravados, o efeito para a pessoa usuária e as consequências de um resultado incorreto.
Em seguida, avalie duas dimensões: o impacto de não conseguir concluir a função e o dano possível caso ela seja concluída com informações incompletas ou incorretas. Essas situações não são equivalentes. Um atraso no carregamento de conteúdo pode ser incômodo, enquanto aceitar uma transação sem verificar seu estado pode gerar perdas ou problemas de conciliação.
Classifique as funções inicialmente em três grupos:
- Podem ser mantidas: recursos que não dependem do serviço indisponível, como consultar conteúdo já disponível localmente.
- Podem ser limitadas: ações úteis se tiverem o escopo reduzido, como exibir dados armazenados com a data da última atualização ou permitir salvar um rascunho sem enviá-lo.
- Devem ser interrompidas: operações cuja correção depende de uma verificação que não pode ser feita, como confirmar uma ação irreversível sem validar suas condições.
A classificação deve considerar alternativas e consequências para as áreas afetadas. A equipe de produto pode definir qual experiência ainda oferece valor; as equipes de tecnologia e operações devem confirmar quais falhas são detectadas e quais garantias os sistemas oferecem. Avalie também as dependências indiretas: uma função pode parecer independente e, ainda assim, precisar de uma validação posterior para concluir o processo.
Escolha entre capacidade limitada, cache ou alternativa manual
A opção adequada depende da idade aceitável dos dados, de a operação alterar ou não o estado e da possibilidade de conciliar as mudanças posteriormente. Nem todo cache é seguro para qualquer uso: um dado útil para orientar uma consulta pode ser inadequado para autorizar uma operação.
- Dados em cache: use-os quando a leitura continuar sendo útil mesmo sem estar totalmente atualizada. Informe a idade dos dados e evite apresentá-los como uma confirmação atual. Defina quando deixam de ser aceitáveis; se não for possível estabelecer esse limite com base em critérios de negócio, não os use em decisões sensíveis.
- Capacidade reduzida: ofereça apenas uma parte da função, como consultar informações sem alterá-las, ou preparar uma solicitação sem enviá-la. Explique qual etapa está pendente e o que será necessário para concluí-la.
- Alternativa manual: pode ser adequada quando há um procedimento claro, responsáveis definidos e um registro posterior. Sem esses controles, o trabalho manual pode criar duplicidades e se tornar uma fonte paralela de dados.
- Bloqueio temporário: é preferível quando a operação não pode ser executada com segurança nem verificada posteriormente. Restrinja a ação afetada, não necessariamente toda a aplicação.
Antes de permitir gravações adiadas, defina como as operações serão identificadas, armazenadas e tentadas novamente; qual resposta será apresentada à pessoa; e como os conflitos serão resolvidos. Se não houver uma regra segura para esses casos, manter a intenção como rascunho costuma ser menos arriscado do que afirmar que a ação foi concluída.
Bloqueie operações que possam deixar dados inconsistentes
A pergunta principal é se o sistema consegue distinguir entre uma solicitação não recebida, uma solicitação processada cuja resposta se perdeu e uma solicitação ainda pendente. Se não conseguir, repetir uma operação sensível sem controles pode executá-la mais de uma vez. As novas tentativas devem ter limites e ser adequadas ao tipo de solicitação; no caso de ações com efeitos, é preciso criar mecanismos para reconhecer duplicidades e consultar o resultado antes de repetir.
Interrompa ou limite uma operação quando:
- ela exigir uma validação que está indisponível e não houver uma regra alternativa aprovada;
- ela puder produzir um efeito irreversível ou difícil de compensar;
- não for possível identificar se uma solicitação anterior foi concluída;
- os dados armazenados tiverem ultrapassado o limite de atualização aceitável para aquela decisão.
Se houver uma forma de compensação, documente quem pode iniciá-la e como ela será registrada. Não presuma que uma ação compensatória equivale a desfazer o efeito original: ela pode exigir intervenção operacional, análise ou comunicação à pessoa afetada. A política deve refletir essas limitações.
Comunique os limites e recupere o serviço de forma controlada
A mensagem deve explicar qual função está limitada, o que a pessoa pode fazer naquele momento e se será necessário repetir alguma etapa. Evite afirmações como “concluído” quando apenas uma solicitação pendente foi salva. Também não prometa um prazo de recuperação que a equipe não possa garantir. Um status claro reduz tentativas repetidas por impulso e contatos evitáveis com o suporte.
Quando a dependência se recuperar, não reative automaticamente tudo o que ficou pendente. Verifique o estado real, processe as operações em uma ordem definida, detecte duplicidades e registre os resultados. Se houver conflitos entre alterações, aplique uma regra acordada — por exemplo, uma revisão antes de sobrescrever — e mantenha rastreabilidade suficiente para investigar divergências.
A recuperação deve seguir condições observáveis. Verifique se a dependência está respondendo de forma estável, se os resultados são válidos e se a aplicação consegue concluir o fluxo normal. Em seguida, remova as restrições de forma controlada. Se os sintomas voltarem, o sistema deve conseguir limitar novamente a função, em vez de alternar entre disponível e indisponível.
Teste as decisões e avalie os resultados
Uma política de degradação que existe apenas em um documento não comprova que a aplicação a executa corretamente. Simule a indisponibilidade, a latência alta, os erros parciais e as respostas tardias de cada dependência importante. Verifique a interface, os registros, as operações pendentes e o comportamento diante de duplicidades. Inclua testes de recuperação e conciliação, não apenas de entrada no modo limitado.
Avalie em conjunto os indicadores técnicos e de negócio. Entre os técnicos estão os erros e tempos de resposta da dependência, o volume de novas tentativas e a duração da degradação. Entre os indicadores de negócio estão as operações bloqueadas, as solicitações pendentes, os conflitos encontrados e os casos que exigem intervenção manual. Uma melhora na disponibilidade não basta se aumentar as transações inconsistentes ou a carga de trabalho do suporte.
Como critério prático, responda e valide quatro perguntas para cada função: o que é mantido, o que é limitado, o que é bloqueado e como a recuperação é confirmada. Se a equipe não conseguir respondê-las, ainda não existe uma estratégia completa. A degradação controlada transforma uma falha inevitável em uma decisão explícita: manter o valor que continua sendo seguro e adiar aquilo que depende de uma garantia temporariamente indisponível.