Quantas vezes já nos deparamos com aquela API externa que estamos consultando dentro de nossas aplicações e a mesma vem a falhar inumeras vezes deixando nossos serviços de mãos vazias e sem saber para onde ir, resultando em atrasos de requisições e deixando o cliente enfurecido ? É problemas como esse que o Circuit Breaker nos apresenta uma saída.
- Fechado (Closed): Tudo funciona normalmente, as requisições passam livremente.
- Aberto (Open): Após um certo número de falhas, o disjuntor “abre”, bloqueando novas requisições por um tempo.
- Meio-aberto (Half-Open): Após um intervalo, algumas requisições-teste são permitidas. Se forem bem-sucedidas, o circuito volta ao estado fechado; se falharem, volta ao aberto.
Por que usar?
- Evita sobrecarregar sistemas que já estão com problema.
- Previne “falhas em cascata” (um serviço quebrado derrubar geral).
- Dá tempo para recuperação (tenta de novo só depois de uma pausa).
Exemplos rápidos
1. API de Pagamento
Você vende ingressos online e usa uma API de pagamentos de terceiros.
O sistema de pagamento cai de repente.
Sem circuit breaker:
- Toda nova tentativa (do usuário ou automática) só piora, lotando ainda mais o serviço.
Com circuit breaker:
- Depois de, por exemplo, 3 falhas, sua aplicação para de enviar requisições por um tempo.
- O usuário recebe retorno rápido (“Tente novamente mais tarde”) e seu sistema não sobrecarrega.
2. Comunicação entre Microserviços
Você tem arquitetura de microserviços e o serviço A faz chamadas HTTP para o serviço B.
- O serviço B trava ou fica lento.
- O A seguiria tentando e esperando timeout, gastando recursos.
- Com circuit breaker: Após falhas seguidas, o A para de tentar por um período, liberando recursos.
3. Gateway de Armazenamento de Arquivos
Um serviço faz uploads para armazenamento na nuvem. O storage passa por uma indisponibilidade temporária.
- Sem circuit breaker: sua aplicação fica tentando e entope a fila.
- Com circuit breaker: bloqueia logo as tentativas, evitando fila acumulada até tudo voltar ao normal.
Configurações principais
- Quantidade de falhas: Quantos erros antes de abrir o circuito?
- Tempo de break: Quanto tempo fica aberto até tentar de novo?
- Exceções: Quais falhas contam? (erros, timeout, etc.)
- Estado meio-aberto: Quantas requisições de teste pra fechar de novo?
Prós e Contras
Prós:
- Previne falhas em cascata
- Reduz desperdício de recursos
- Dá resposta rápida ao usuário
Contras:
- Requer ajuste cuidadoso
- Pode atrasar a recuperação
- Adiciona um pouco de complexidade
Pensamento final
O circuit breaker é uma ferramenta simples e poderosa para tornar seu sistema mais resiliente, principalmente em arquiteturas distribuídas ou na nuvem. Fácil de implementar (principalmente com bibliotecas como Polly no .NET), ele transforma grandes quedas em problemas pontuais — e seus usuários seguem felizes, mesmo quando outros serviços falham! É sempre importante levar em consideração a tratativa de falhas quando estamos nos comunicando com outros sistemas.
No próximo artigo irei mostrar como podemos utilizar esse padrão no .NET com a biblioteca Polly.