# Circuit Breaker: como implementar em microsservicos (guia) > Circuit Breaker é um padrão de resiliência para microsserviços que previne falhas em cascata. A implementação envolve selecionar bibliotecas como Hystrix ou Resilience4j, configurar thresholds de falha e timeouts, e testar cenários de abertura e fechamento do circuito. O guia prático cobre desde a escolha da ferramenta até testes de resiliência para garantir estabilidade do sistema. *PosUp · Apps e Software · 27 de julho de 2026 · Patrícia Lemos* Implementar circuit breaker em microsservicos evita que uma falha em um serviço derrube todo o sistema. Neste guia, mostramos o passo a passo para configurar o padrão, desde a escolha da biblioteca até os testes de resiliência. Implementar circuit breaker em microsservicos significa proteger seu sistema contra falhas em cascata. Quando um serviço dependente falha, o circuit breaker interrompe as chamadas automaticamente, evitando que a instabilidade se espalhe. O resultado esperado: um sistema resiliente que se recupera sozinho. Pré-requisitos: conhecimento básico de microsservicos e uma biblioteca de resiliência (Resilience4j, Hystrix ou Spring Cloud Circuit Breaker). ## Passo 1: Escolha a biblioteca e configure o monitoramento Selecione uma biblioteca compatível com sua stack. Resilience4j é a escolha mais comum para Java moderno, pois substituiu o Hystrix (descontinuado). Configure o monitoramento para registrar o número de chamadas, falhas e tempos de resposta. Sem monitoramento, você não consegue ajustar os thresholds. **Erro comum:** usar a biblioteca sem configurar métricas. Você precisa de um dashboard (Prometheus + Grafana, por exemplo) para enxergar quando o circuito abre. ## Passo 2: Defina os thresholds de abertura do circuito Determine quantas falhas consecutivas ou qual percentual de erro deve disparar o circuit breaker. Um valor inicial comum: 5 falhas em 10 segundos, ou 50% de taxa de erro. Ajuste conforme o comportamento real do serviço. **Dica:** comece com thresholds mais baixos (menos tolerância a falhas) e aumente gradualmente. Um circuito que abre cedo demais protege mais, mas pode causar falsos positivos. ## Passo 3: Implemente o estado half-open e o timeout O circuit breaker tem três estados: fechado (normal), aberto (bloqueia chamadas) e half-open (testa recuperação). Configure o tempo que o circuito fica aberto antes de tentar uma requisição de teste (ex.: 30 segundos). Se a chamada de teste falhar, volta para aberto; se bem-sucedida, fecha o circuito. **Erro comum:** esquecer de configurar o timeout. Sem timeout, uma chamada lenta mantém o circuito aberto por tempo indefinido. Defina um timeout agressivo (ex.: 2 segundos) para serviços críticos. ## Passo 4: Adicione fallback para quando o circuito abrir Quando o circuit breaker abre, sua aplicação precisa de uma resposta alternativa (fallback). Pode ser um valor em cache, uma mensagem padrão ou uma chamada a um serviço secundário. O fallback evita que o usuário veja um erro 500. **Dica:** registre logs sempre que o fallback for acionado. Isso ajuda a identificar padrões de falha e ajustar os thresholds. ## Passo 5: Teste com injeção de falhas Simule falhas nos serviços dependentes usando ferramentas como Chaos Monkey ou Toxiproxy. Verifique se o circuit breaker abre no tempo esperado, se o fallback é chamado e se o sistema se recupera sozinho. **Erro comum:** testar apenas em ambiente de desenvolvimento. O comportamento em produção (latência real, volume de requisições) é diferente. Faça testes de carga com falhas injetadas. ## Checklist do que foi implementado - [ ] Biblioteca de circuit breaker configurada com métricas - [ ] Thresholds de falha definidos (ex.: 5 falhas em 10s) - [ ] Timeout configurado para chamadas lentas - [ ] Estado half-open com tempo de espera ajustado - [ ] Fallback implementado para cada serviço crítico - [ ] Testes de injeção de falhas realizados ## FAQ ### Qual a diferença entre circuit breaker e retry? Retry tenta novamente a chamada que falhou, geralmente com backoff. Circuit breaker bloqueia todas as chamadas por um período quando a taxa de erro ultrapassa o limite. Eles são complementares: use retry para falhas transitórias e circuit breaker para falhas persistentes. ### Como escolher entre Resilience4j e Hystrix? Hystrix foi descontinuado pela Netflix. Resilience4j é a alternativa moderna, com menor overhead e suporte a Spring Boot 3. Para projetos novos, prefira Resilience4j. Para sistemas legados, planeje a migração. ### O circuit breaker funciona para chamadas síncronas e assíncronas? Sim. Em chamadas síncronas (HTTP), ele bloqueia a thread. Em assíncronas (filas, eventos), ele impede o envio da mensagem. A configuração de thresholds e timeout se aplica a ambos os casos. ### Como monitorar o estado do circuit breaker em produção? Exponha métricas via endpoints (ex.: /actuator/health no Spring) e colete com Prometheus. Crie alertas para quando o circuito abrir com frequência, indicando degradação do serviço dependente. ### O que acontece se o fallback também falhar? O fallback deve ser projetado para não depender do serviço original. Se falhar, a aplicação precisa retornar um erro amigável (ex.: "Serviço temporariamente indisponível") e registrar o incidente. Considere um fallback em cache estático como última opção. --- Fonte (canonical): https://posup.com.br/apps-e-software/circuit-breaker-como-implementar-em-microsservicos-guia/