Circuit breaker na prática

O problema

Tem integração que adoece e arrasta o resto junto.

O fluxo costuma ser assim:

• serviço A depende do serviço B
• serviço B fica lento ou instável
• serviço A continua tentando em toda request
• threads, conexões e fila interna vao lotando
• de repente o problema de B também virou problema de A

Isso acontece porque insistir demais também e um tipo de falha.

Modelo mental

Circuit breaker e um mecanismo para responder esta pergunta:

quando uma dependência esta falhando demais, faz sentido continuar tentando agora?

Se a resposta for não, o sistema para de insistir por um tempo e falha rápido.

O nome ajuda a lembrar do disjuntor eletrico:

• normal: circuito fechado
• falha demais: circuito abre
• depois de um tempo: testa se pode fechar de novo

Não e magia.

E controle de dano.

Quebrando o problema

Fechado: o comportamento normal

Enquanto a dependência esta saudavel, as chamadas seguem normalmente.

O circuito fechado significa:

• pode chamar
• mede sucesso e falha
• continua observando

Aberto: para de insistir

Quando a taxa de erro ou timeout passa de certo limite, o circuito abre.

Abrir significa:

• não mandar novas chamadas por um período
• falhar rápido
• liberar o resto do sistema para seguir com fallback, erro controlado ou degradação

Esse ponto importa bastante.

Abrir o circuito não cura a dependência.

Só evita que você continue queimando recurso em algo que já está ruim.

Meio-aberto: testa a volta

Depois de um intervalo, o sistema deixa passar algumas tentativas controladas para testar a volta.

Se der certo, fecha de novo. Se continuar falhando, abre outra vez.

Isso evita dois extremos:

• testar nunca mais
• liberar tudo de uma vez cedo demais

Circuit breaker não substitui timeout

Esse erro aparece muito.

Sem timeout, a chamada pode continuar pendurada tempo demais.

Sem retry bem desenhado, falha transitoria pequena vira erro desnecessario.

Sem circuit breaker, dependência doente continua arrastando recurso seu.

Cada mecanismo resolve uma parte:

• timeout limita espera
• retry tenta falha transitoria
• circuit breaker para a insistencia quando o padrão já virou colapso

Fallback precisa ser honesto

Quando o circuito abre, o sistema pode:

• responder erro claro
• servir dado degradado
• usar cache
• pular funcionalidade secundaria

O importante e o fallback ser coerente com o negócio.

Não adianta devolver dado perigoso só para esconder que a dependência caiu.

Exemplo simples

Imagine checkout chamando serviço antifraude.

Se o antifraude começa a responder em 8 segundos ou a falhar 70% das vezes, cada novo pagamento vai acumulando espera.

Sem proteção:

• usuário espera demais
• pool de conexão fica preso
• fila interna cresce
• o checkout começa a parecer quebrado mesmo quando o resto dele esta bom

Com circuit breaker:

1. o sistema detecta degradação forte
2. abre o circuito
3. novas requests falham rápido ou entram em fluxo degradado
4. depois de um tempo, algumas tentativas testam recuperação

Isso não e bonito só no diagrama.

E o tipo de decisão que impede um incidente local de virar cascata.

Erros comuns

• Achar que retry sempre ajuda.
• Abrir circuito sem timeout bem definido.
• Usar limite genérico sem pensar no comportamento da dependência.
• Não ter fallback nem mensagem clara para o caso aberto.
• Medir só erro explícito e ignorar timeout ou latência ruim como sinal de degradação.

Como um senior pensa

Quem tem mais experiência olha para integração ruim e pergunta:

“Se essa dependência adoecer agora, eu vou adoecer junto ou consigo isolar o dano?”

Essa pergunta muda o desenho.

Sai da lógica de “tentar até dar certo” e entra na lógica de resiliencia.

Porque em produção insistência cega parece perseverança só até a primeira cascata.

O que o entrevistador quer ver

Em entrevista, circuit breaker costuma aparecer como parte de resiliencia de serviços.

O avaliador quer ver se você entende o comportamento, não só o nome do padrão.

Sinais bons:

• você diferencia timeout, retry e circuit breaker
• fala de falhar rápido
• menciona estados fechado, aberto e meio-aberto
• conecta isso a proteção de recurso e degradação controlada

Uma resposta forte costuma soar assim:

“Se a dependência esta falhando acima de certo limiar, eu paro de insistir por um tempo. Isso reduz latência, protege recurso local e evita que a falha dela vire uma cascata no meu sistema.”

Circuit breaker não deixa serviço terceiro saudável. Ele só impede que a doença dele vire hemorragia interna no seu.