Como impedir que uma dependência externa indisponível paralise o sistema inteiro

O que você vai levar deste guia

• Relacione o tempo de espera ao prazo total da tarefa.
• Isole a capacidade usada pela dependência e classifique as falhas.
• Defina uma saída operacional verdadeira para o período de indisponibilidade.

Identifique como a falha se espalha

Quando uma API externa demora, o impacto pode ir além da tela que a consulta. Conexões, memória e trabalhadores ficam ocupados esperando. Novas solicitações se acumulam e outras tarefas começam a falhar. Antes de adicionar tentativas, desenhe quais recursos são compartilhados e quanto tempo permanecem retidos. A pergunta é como impedir que uma dependência comprometida consuma toda a capacidade local, preservando as funções que ainda podem operar.

No exemplo fictício da empresa Agenda de Campo, o sistema consulta um serviço externo para estimar deslocamento entre visitas. Durante uma instabilidade, a montagem de rotas demora e o cadastro básico de equipes também fica lento porque ambos usam o mesmo conjunto de trabalhadores. O objetivo é conter a espera da estimativa e manter as demais funções utilizáveis. Isso não significa inventar tempos de deslocamento; significa separar o que depende da confirmação externa do que pode continuar.

Registre as tarefas afetadas e sua criticidade. Uma consulta informativa pode aceitar uma resposta de indisponibilidade. Uma confirmação que exige o dado externo talvez precise ficar pendente. Um processamento em segundo plano pode aguardar outra janela. A mesma falha técnica pede saídas distintas, e o mecanismo de resiliência deve respeitar esses contratos em vez de devolver a mesma mensagem ou valor para todos os usos.

Defina um orçamento de tempo para a tarefa completa

Comece pelo prazo em que a resposta ainda é útil ao usuário. Distribua esse tempo entre processamento local, chamadas externas e margem para devolver uma resposta compreensível. Se uma tarefa tem várias dependências sequenciais, não atribua a cada uma o prazo total. A soma pode ultrapassar muito a expectativa. Meça o caminho real e identifique quais chamadas ocorrem em paralelo, evitando somar durações sobrepostas de forma incorreta.

Defina limites de conexão e de resposta conforme o cliente e o serviço utilizados. Uma espera sem limite pode reter recursos indefinidamente; um limite curto demais pode rejeitar operações normais. Use a distribuição observada e a necessidade da tarefa para escolher valores iniciais, identificando-os como decisões locais. Não copie um número de outro sistema sem comparar volume, rede e comportamento da dependência.

Na Agenda de Campo fictícia, o planejamento interativo tem um prazo menor que uma recomposição noturna. Essas operações podem usar políticas diferentes, desde que coordenadas com a capacidade externa. O usuário deve receber um resultado ou uma condição de pendência antes de abandonar a tarefa por falta de resposta. O orçamento de tempo é parte do produto: determina quando parar de esperar e qual continuidade oferecer.

Classifique erros antes de contar falhas

Nem toda resposta negativa indica indisponibilidade. Uma solicitação inválida, um recurso inexistente e uma falha de autenticação exigem ações diferentes de uma interrupção transitória. Se todos esses casos alimentam o mesmo mecanismo, poucos dados incorretos podem interromper uma dependência saudável para todos. Defina quais sinais indicam falha do serviço e quais pertencem ao conteúdo ou à configuração da solicitação.

A documentação da Microsoft sobre Circuit Breaker descreve um mecanismo que interrompe chamadas a uma dependência com falhas e permite verificar sua recuperação. Essa proteção complementa limites de espera, mas depende de critérios adequados de abertura e retorno. O método aqui aplica a ideia ao serviço fictício de deslocamento, com classificação de erros e saídas operacionais definidas pela aplicação.

Registre a classificação com evidências suficientes. Um timeout pode significar serviço lento, rede ou limite local inadequado; ele não explica sozinho a causa. O mecanismo pode reagir ao sinal para proteger capacidade enquanto a investigação continua. Evite transformar a proteção em uma afirmação definitiva de que o fornecedor caiu. Na comunicação operacional, diferencie “não conseguimos confirmar agora” de uma conclusão sobre a infraestrutura de terceiros que ainda não foi verificada.

Escolha a unidade de proteção e isole capacidade

Defina a abrangência do circuito: serviço, endpoint, região ou contexto de credencial, conforme a dependência. Uma falha em uma operação específica não deve necessariamente interromper consultas independentes. Por outro lado, circuitos locais demais podem deixar centenas de trabalhadores insistindo separadamente no mesmo destino comprometido. A unidade precisa refletir a relação entre capacidade compartilhada e falha observada.

Isole recursos quando necessário. Um conjunto limitado de trabalhadores para estimativas de deslocamento pode impedir que essa espera ocupe os responsáveis pelo cadastro de equipes. Defina limites de fila e comportamento quando a capacidade é atingida. Uma fila sem limite apenas transforma indisponibilidade imediata em atraso crescente e uso de memória. A admissão de trabalho precisa considerar se ele ainda terá utilidade quando chegar sua vez.

Teste o isolamento com a dependência deliberadamente lenta. Verifique se funções não relacionadas mantêm o comportamento esperado e se a aplicação rejeita ou adia novas tarefas de forma controlada. Observar apenas o circuito não basta: os recursos podem já estar ocupados antes de ele abrir. O desenho completo combina orçamento de espera, capacidade reservada e decisão sobre novas entradas, conforme a carga e a arquitetura disponíveis.

Defina o que acontece enquanto a proteção está ativa

Quando o circuito impede a chamada, a tarefa precisa receber uma saída apropriada. Para uma estimativa informativa, pode mostrar indisponibilidade. Para um planejamento que aceita cálculo posterior, pode salvar o rascunho e marcar estimativa pendente. Para uma confirmação que depende do valor atual, pode impedir a conclusão e explicar o motivo. Não transforme ausência de resposta em zero, aprovação ou sucesso apenas para evitar erro na interface.

Se houver um resultado anterior reutilizável, avalie sua validade para a tarefa. Um tempo de deslocamento calculado para outro contexto pode não servir. Quando for permitido mostrar um retrato anterior, identifique sua referência e limitação. A pessoa precisa saber se está vendo informação confirmada agora ou uma ajuda provisória. O fallback é uma decisão de negócio e de experiência, não apenas um retorno padrão em um bloco de exceção.

Na empresa fictícia, o supervisor pode continuar editando a sequência de visitas, mas a plataforma indica que a validação de deslocamento está pendente. A Tironi Tech pode desenvolver essa separação entre edição e confirmação, junto dos mecanismos de proteção. O objetivo é preservar trabalho útil durante a falha sem ocultar a dependência que ainda falta para concluir a decisão operacional.

Coordene novas tentativas com a recuperação

Tentativas automáticas precisam caber no orçamento de tempo e considerar se a operação pode ser repetida. Repetir uma leitura pode ter consequências diferentes de repetir uma ação que produz efeito externo. O circuito não substitui essa análise. Evite camadas de repetição independentes no cliente, serviço e trabalhador, porque a multiplicação pode gerar muito mais chamadas do que o planejado. Registre onde a política é aplicada e quem decide a próxima tentativa.

Quando chegar o momento de verificar recuperação, limite as chamadas de teste e observe seus resultados. Uma resposta bem-sucedida pode indicar melhora, mas não provar capacidade para toda a carga acumulada. Defina critérios e uma retomada compatível com o serviço. Se as sondagens falham, volte à proteção sem liberar uma rajada. O comportamento precisa ser testado sob carga, não apenas com um endpoint que alterna entre sucesso e falha instantâneos.

Considere instâncias múltiplas. Se cada uma decide recuperar no mesmo instante, o conjunto pode produzir um pico. A coordenação ou distribuição das tentativas deve refletir o volume e a arquitetura. Não é necessário adicionar um sistema complexo para qualquer aplicação pequena, mas é necessário entender a soma dos comportamentos locais. A recuperação deve aliviar a dependência e permitir observar estabilidade, em vez de recriar a condição que motivou a proteção.

Observe impacto, estado e tarefas pendentes

Acompanhe tempo de resposta, falhas classificadas, estado do circuito, chamadas evitadas e capacidade local. Relacione esses sinais à tarefa: quantos planejamentos ficaram pendentes e por quanto tempo. Um circuito aberto pode estar protegendo corretamente o sistema, mas a operação ainda precisa tratar a falta de estimativas. A visão técnica e a visão de negócio devem se complementar para orientar suporte e comunicação.

Defina alertas que indiquem uma ação. Aberturas breves dentro de um comportamento conhecido podem não exigir intervenção imediata, enquanto uma proteção prolongada ou repetitiva pode precisar de investigação. Use metas locais e registre a duração, sem apresentar números universais como regra. O alerta deve levar a uma pergunta concreta: houve mudança de configuração, falha do fornecedor, aumento de carga ou um limite de espera inadequado?

Depois da recuperação, acompanhe o acumulado. Tarefas antigas podem ter perdido utilidade ou precisar de nova validação antes de executar. No exemplo fictício, estimar uma rota já encerrada pode ser desnecessário, enquanto um rascunho ainda ativo precisa continuar. Defina essa distinção para não gastar a capacidade recém-recuperada com trabalho obsoleto. A proteção termina tecnicamente antes de todas as consequências operacionais estarem resolvidas.

Teste degradação e documente limites

Prepare cenários de lentidão, falha persistente, erro de validação, recuperação parcial e oscilação. Confira que apenas os sinais definidos afetam o circuito e que o fallback mantém o significado da tarefa. Teste também indisponibilidade do mecanismo de configuração ou monitoramento quando ele participa da decisão. A aplicação deve ter um comportamento padrão conhecido, sem depender de uma cadeia de proteção que falha de modo indefinido.

Meça funções não relacionadas durante a falha simulada para comprovar isolamento. Verifique que filas permanecem limitadas e que o usuário consegue entender pendências. Depois, teste retomada com volume acumulado e confirme que não há efeitos repetidos indevidamente. A evidência precisa mostrar contenção e recuperação, não apenas que uma exceção foi capturada ou que um contador mudou de estado.

Finalize com um mapa de dependências, políticas de espera, classificação de erros e saídas de contingência. Registre quem pode ajustar parâmetros e como validar uma mudança. Uma dependência continuará podendo falhar; o objetivo é que essa falha tenha alcance e duração administráveis no seu sistema. A operação ganha previsibilidade quando sabe o que continua funcionando, o que está pendente e quais evidências permitem retomar o fluxo completo.

Perguntas frequentes

Timeout e circuit breaker fazem a mesma coisa?

Não. O timeout limita a espera de uma tentativa. O circuit breaker usa um estado de proteção para evitar insistir continuamente em uma dependência com falhas.

Posso devolver um valor padrão quando a API falha?

Somente se esse valor tiver um significado correto para a tarefa. Ausência de confirmação não deve ser convertida em aprovação ou dado inventado.

O serviço deve receber todo o tráfego assim que responder uma vez?

Não necessariamente. A recuperação pode exigir sondagens e retomada gradual, porque uma resposta isolada não demonstra capacidade para a carga completa.

Reduza o impacto das falhas de integração

A Tironi Tech pode analisar dependências, desenvolver controles de resiliência e definir experiências de contingência conforme as tarefas do seu sistema.

Artigos relacionados

• Mapa de exposição empresarial a sistemas de IA: como localizar fluxos de dados, decisões assistidas e dependências externas
• Gestão de incidentes em sistemas de IA: como detectar, conter, comunicar e aprender com falhas probabilísticas
• Como ensaiar a restauração de um sistema sem interferir na produção

Fontes consultadas

• Microsoft — Circuit Breaker pattern