Um sistema de pagamento chama um serviço externo de validação de cartão que, por algum motivo, começou a responder devagar, sem chegar a falhar completamente. Rolando Bonaccorsi, diretor de operações da Vert Analytics, além de especialista em gestão de operações de TI e excelência em serviços, observa que esse cenário, aparentemente menos grave do que uma indisponibilidade total, costuma causar dano maior à operação inteira do que uma falha limpa e imediata.
O padrão circuit breaker existe justamente para essa situação, emprestando o nome do disjuntor elétrico doméstico: assim como esse dispositivo interrompe a energia diante de sobrecarga, o padrão de software interrompe chamadas a um serviço problemático antes que o problema se espalhe para o resto do sistema.
O disjuntor que empresta o nome ao padrão
Em condições normais, o circuit breaker permanece no estado fechado, deixando toda chamada passar livremente até o serviço dependente, enquanto monitora silenciosamente a taxa de falhas e o tempo de resposta de cada requisição realizada.
Quando as falhas ultrapassam um limite predefinido, o circuito abre: novas chamadas param de ser enviadas ao serviço problemático e recebem imediatamente um erro tratado, ou uma resposta alternativa vinda de cache, em vez de esperar indefinidamente por uma resposta que talvez nunca chegue dentro de tempo aceitável.
Esse limite de falhas, junto com o tempo que o circuito permanece aberto antes de testar novamente, são parâmetros configuráveis que cada equipe ajusta conforme a criticidade e o comportamento esperado de cada dependência específica, não valores universais aplicáveis sem qualquer calibração ao contexto real da aplicação.
Por que uma dependência lenta é pior do que uma fora do ar?
Um serviço completamente fora do ar gera erro imediato, fácil de identificar e tratar. Um serviço lento, por outro lado, mantém conexões abertas por muito mais tempo, consumindo recursos como threads e conexões de banco de dados que ficam presas esperando uma resposta que demora a chegar.
Conforme Rolando Bonaccorsi destaca, uma máxima conhecida entre engenheiros de confiabilidade é: melhor um serviço fora do ar do que um serviço lento. Um serviço lento tende a esgotar recursos compartilhados de toda a aplicação, derrubando funcionalidades que, tecnicamente, nem dependem daquele serviço específico que está degradado, um efeito cascata que uma falha rápida e limpa simplesmente não provoca.
Esse efeito cascata explica incidentes que, à primeira vista, parecem não ter relação alguma entre si: uma funcionalidade de busca lenta pode, em teoria, derrubar o checkout de um site inteiro, simplesmente porque as duas funcionalidades competem pelo mesmo pool limitado de conexões disponíveis no servidor compartilhado por toda a aplicação.
O estado meio-aberto: testando a volta sem arriscar tudo
Depois de um período determinado com o circuito aberto, o sistema não assume simplesmente que o problema foi resolvido. Ele entra em um terceiro estado, meio-aberto, permitindo passar um número limitado de chamadas de teste para verificar se o serviço realmente voltou a funcionar normalmente.
Rolando Bonaccorsi explica que esse estado intermediário evita dois extremos problemáticos: reabrir o circuito completamente e sobrecarregar de novo um serviço que talvez ainda esteja se recuperando, ou manter o circuito fechado por tempo desnecessariamente longo depois que o problema original já foi resolvido pela equipe responsável.
Onde aplicar primeiro?
Nem toda chamada entre sistemas precisa de circuit breaker, mas dependências externas críticas, especialmente aquelas fora do controle direto da equipe, como serviços de terceiros ou integrações de pagamento, se beneficiam imediatamente dessa proteção adicional.
Rolando Bonaccorsi recomenda priorizar a implementação desse padrão exatamente nesses pontos de maior risco de falha em cascata, onde uma dependência externa lenta ou instável tem potencial de comprometer funcionalidades internas que, isoladamente, nada têm a ver com o problema que originalmente começou fora dos limites da própria aplicação.
Implementar circuit breaker em todas as chamadas do sistema, sem qualquer critério de priorização, também gera custo desnecessário de complexidade. O equilíbrio certo está em mapear quais dependências realmente representam risco de cascata e concentrar esse investimento de proteção exatamente onde uma falha silenciosa custaria mais caro para o restante da operação.