Alguns anos atrás, participei da análise de uma falha que gerou bastante prejuizo para uma empresa de grande porte. O sistema caiu por completo — não por causa de um ataque, nem por erro no código — mas por algo mais sutil: um efeito dominó causado por falhas em serviços dependentes. Um microsserviço começou a falhar, os outros ficaram insistindo nas chamadas, o tráfego explodiu, ninguém conseguiu mais responder e… tudo foi ao chão. Literalmente.
Esse tipo de situação acontece com mais frequência do que deveria. E o pior: é evitável. Possuem algumas estratégias que em conjunto são necessárias, como retry/timout e também circuit breaker… mas hoje quero focar apenas no circuit Breaker.
Circuit Breaker é um pattern simples, mas que pode salvar a sua aplicação de cair inteira só porque um pedaço falhou.
Aliás, esse tipo de conteúdo é o que eu mais compartilho na Comunidade de Arquitetura Descomplicada (CaD), se tiver interesse em saber mais não deixe de acessar https://mugnos-it.com/cad/
Se você curte arquiteturas resilientes de verdade, vai se sentir em casa por lá.
O que é Circuit Breaker?
Se você já viu um disjuntor elétrico, sabe como ele funciona: quando algo dá errado, ele desliga o circuito para evitar um incêndio.
O Circuit Breaker na arquitetura de software faz a mesma coisa. Ele identifica quando um serviço ou componente começa a falhar repetidamente e, ao invés de deixar a aplicação continuar insistindo e quebrar tudo de vez, ele interrompe temporariamente as chamadas, protegendo o sistema.
Sem Circuit Breaker: o caos
Imagina um sistema de reserva de viagens, onde o backend central consulta serviços de avião, hotel e aluguel de carros. Se o serviço de carros cair, sem circuit breaker, a aplicação vai:
- Tentar bater no serviço várias vezes;
- Gastar threads e recursos com timeouts inúteis;
- Gerar um retry storm, travando até quem estava funcionando;
- Quando o serviço de carros tentar voltar, ele toma uma avalanche de requisições e… cai de novo.
Resultado? Todo o sistema começa a falhar — mesmo partes que estavam 100% saudáveis.
Com Circuit Breaker: controle
Com o pattern implementado, quando o serviço de carros cair, o breaker entra em estado “open” (Sim, open não quer dizer que esta passando requisição, aqui Open é igual circuit breaker eletrico, ele evita que a eletricidade passe). Ou seja: ele para de enviar requisições para aquele serviço por um tempo, retornando imediatamente com um fallback ou erro tratado.
Isso traz diversos benefícios:
- Evita sobrecarga nos serviços falhos;
- Preserva os recursos do sistema principal;
- Garante resposta rápida ao usuário, mesmo em caso de falha;
- Evita o famoso efeito dominó.
Como funciona na prática?
O Circuit Breaker tem três estados principais:
- Closed (Fechado) – tudo normal, chamadas fluem normalmente.
- Open (Aberto) – o serviço falhou N vezes, bloqueia chamadas por um tempo.
- Half-Open – começa a testar devagar se o serviço voltou. Se sim, volta para fechado.
Exemplo real: um serviço caiu por instabilidade. O breaker entrou em open após 5 falhas. Esperou 30 segundos. Depois, entrou em half-open e enviou 2 requisições. Ambas deram sucesso. Voltou para closed e o sistema seguiu, sem crash, sem drama.
🧱 Onde implementar?
O ideal é implementar em camada de rede ou gateway, como:
- Istio (Service Mesh)
- Envoy
- Spring Cloud Gateway
- API Gateway de nuvem (ex: AWS, Azure)
Também pode ser implementado na aplicação com bibliotecas como Resilience4j, Hystrix (legado), ou middlewares próprios.
Mas atenção: não confunda Circuit Breaker com Rate Limiting ou Throttling!
- Circuit Breaker ≠ limitar requisições
- Circuit Breaker ≠ negar carga excessiva
- Circuit Breaker = proteger o sistema de falhas conhecidas e constantes
🛠 Exemplos práticos de implementação
1. Istio (camada de rede)
Com Istio, você pode configurar circuit breakers diretamente no DestinationRule:
Esse exemplo ejetaria o serviço de carros da rota se ele responder 3 erros 5xx consecutivos em 5s.
2. Resilience4j (na aplicação)
No Spring Boot, por exemplo, é possível aplicar com Resilience4j de forma simples:
Simples, direto, e já com fallback amigável.
Dicas práticas
- Combine com timeout e retry — bem calibrados.
- Use métricas reais: % de falhas, latência, erro HTTP.
- Fallbacks são essenciais (ex: cache, dummy response, fila).
Já vi Circuit Breaker salvar sistemas inteiros
Teve um caso em que, sem circuit breaker, uma aplicação global precisou bloquear o tráfego de usuários no firewall para conseguir se recuperar. Foi um desastre. (fiz uma aula dessa esses dias, aconteceu com o Canva)
Evitar isso com uma linha no gateway e um pattern bem aplicado teria feito toda a diferença.
Conclusão
Circuit Breaker é simples, poderoso e essencial em sistemas modernos.
Especialmente com arquiteturas distribuídas, microserviços, cloud e integrações externas — você não pode ignorar esse pattern.
Esse é o tipo de conhecimento que vai te poupar noites em claro, crises e prejuízos. E é exatamente o tipo de tema que a gente vive debatendo lá na Comunidade de Arquitetura Descomplicada (CaD).
👉 Quer entender mais, ver aulas práticas e aprofundar sua arquitetura? Conheça o CaD.
Abraços.
Douglas Mugnos!
