Circuit breaker interno entre módulos

O problema

Circuit breaker é uma ferramenta boa.

Mas muita equipe descobre isso e exagera:

• qualquer chamada interna ganha breaker
• qualquer oscilação vira abertura
• qualquer timeout já liga modo degradado

No começo parece resiliência.

Depois vira comportamento difícil de prever.

O sistema começa a falhar por autoproteção antes mesmo de entender o que está acontecendo.

Modelo mental

Circuit breaker não existe para “deixar mais robusto” genericamente.

Ele existe para impedir que uma fronteira instável continue contaminando o resto do sistema.

Então a pergunta útil é:

• essa chamada interna pode degradar o core se continuar insistindo?
• existe fallback útil?
• o custo de abrir breaker é melhor do que o custo de insistir?

Sem isso, breaker vira ritual.

Exemplo simples

Imagine um módulo de checkout chamando módulo de cálculo promocional.

Se essa chamada atrasar demais, pode travar o caminho crítico.

Talvez faça sentido:

• limitar tempo
• abrir breaker depois de falha repetida
• seguir sem promoção em modo parcial por alguns minutos

Agora imagine usar o mesmo padrão em uma chamada rápida de leitura local entre módulos do mesmo monólito, sem fallback claro.

Aí o breaker provavelmente não resolve o problema.

Só cria mais um estado intermediário para explicar.

O erro comum

O erro comum é pular direto para:

“coloca circuit breaker”

Às vezes o problema real é:

• timeout grande demais
• retry agressivo
• chamada síncrona que nem deveria existir
• pico interno sem isolamento
• dependência de prazo impossível

Breaker em cima disso pode até reduzir dano.

Mas também pode esconder a causa por mais tempo.

O que normalmente ajuda

Normalmente ajuda tratar breaker como última contenção de uma fronteira específica.

Na prática, a conversa costuma ser:

• esse módulo realmente é frágil?
• quando falha, o que precisa continuar funcionando?
• o fallback é honesto ou só mascara erro?
• qual janela de abertura faz sentido aqui?

Também ajuda garantir que o time saiba diferenciar:

• lentidão momentânea
• saturação real
• erro sistêmico

Sem essa diferença, o breaker abre por ansiedade.

Como um senior pensa

Quem já viu breaker espalhado demais costuma perguntar:

• estou protegendo o sistema ou multiplicando estados de falha?
• essa fronteira precisa de breaker ou de desenho melhor?
• quando ele abrir, o produto continua aceitável?
• consigo operar isso sem transformar incidente em caça ao estado do breaker?

Essa conversa evita bastante “resiliência decorativa”.

Ângulo de entrevista

Esse tema aparece em backend, system design, resiliência e integrações entre serviços ou módulos.

O entrevistador quer ver se você entende:

• quando breaker faz sentido de verdade
• que fallback ruim pode ser pior que erro explícito
• que breaker não substitui timeout, isolamento e bom desenho de fluxo

Resposta forte costuma soar assim:

“Eu só colocaria circuit breaker em fronteiras internas que realmente possam contaminar o resto do sistema e onde exista um modo degradado claro. Se não houver fallback útil, talvez o problema seja timeout, isolamento ou até a própria escolha de manter essa chamada síncrona.”

Takeaway direto

Circuit breaker interno bom protege fronteira crítica.

Circuit breaker em tudo vira superstição operacional.