# Circuit Breaker Microservices: guia de implementação passo a passo > Circuit Breaker Microservices é um padrão de resiliência que previne falhas em cascata em arquiteturas distribuídas. A implementação passo a passo inclui configurar thresholds de falha, timeouts e estados (fechado, aberto, semi-aberto) em bibliotecas como Hystrix ou Resilience4j. O guia prático oferece um checklist final com métricas de monitoramento e testes de carga para validar a proteção contra degradação de serviços. *Blog Sem Juízo · Destaques · 24 de julho de 2026 · Tomás Wenzel* Implementar circuit breaker em microservices exige mais que código. Este guia mostra o passo a passo para evitar falhas em cascata, com dicas reais de configuração e um checklist final. Imagine que seu sistema de microservices está funcionando bem até que um serviço de pagamento começa a responder com erros. As requisições se acumulam, threads travam, e em minutos o colapso se espalha para os serviços vizinhos. O circuit breaker é o padrão de projeto que impede esse efeito dominó, cortando a corrente antes que o curto chegue ao resto da arquitetura. Este guia mostra como implementar circuit breaker em microservices em etapas sequenciais, com instruções claras e erros comuns a evitar. Você precisará de um ambiente com dois ou mais serviços se comunicando via HTTP e um gerenciador de dependências (Maven ou Gradle). ## Passo 1: Identificar os pontos de falha no fluxo Antes de escrever código, mapeie todas as chamadas remotas entre serviços. O circuit breaker só faz sentido onde há latência ou instabilidade, não aplique em chamadas locais ou síncronas de curta duração. Liste cada endpoint externo que seu serviço consome e classifique por criticidade. **Erro comum:** aplicar o padrão em chamadas internas ao mesmo processo, o que adiciona complexidade desnecessária sem benefício real. ## Passo 2: Escolher a biblioteca de implementação No ecossistema Java, as opções mais maduras são Resilience4j (sucessor do Hystrix, descontinuado) e Spring Cloud Circuit Breaker, que abstrai diferentes provedores. Para .NET, existe o Polly. Escolha uma biblioteca com manutenção ativa e que exponha métricas para monitoramento. **Dica:** prefira Resilience4j se você não usa Spring Boot, ou Spring Cloud Circuit Breaker se já tem o ecossistema Spring. Ambas permitem configurar thresholds sem recompilar. ## Passo 3: Configurar os parâmetros do circuit breaker Três parâmetros são essenciais: o threshold de falhas (quantas chamadas precisam falhar para abrir o circuito), o timeout por requisição e o tempo de espera antes de tentar novamente (período de sleep). Um exemplo típico: 5 falhas em 10 segundos, com timeout de 2 segundos e sleep de 30 segundos. **Erro comum:** usar thresholds muito baixos. Um pico momentâneo de latência não justifica abrir o circuito. Ajuste com base em métricas reais de produção, não em suposições. ## Passo 4: Envolver a chamada remota com o circuit breaker No código, substitua a chamada direta ao serviço externo por um invólucro que aplica a lógica do padrão. Em Resilience4j, você cria um CircuitBreaker e usa decorateSupplier ou executeSupplier. Em Spring Cloud, anota o método com @CircuitBreaker(name = "meuServico"). // Exemplo com Resilience4j CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("servicoPagamento"); Supplier supplier = () -> servicoPagamento.realizarPagamento(pedido); String resultado = circuitBreaker.executeSupplier(supplier); **Dica:** sempre defina um fallback, um método alternativo que retorna um valor padrão ou nulo quando o circuito abre. Sem fallback, a exceção sobe para o cliente. ## Passo 5: Definir o comportamento de fallback O fallback é a resposta alternativa quando o circuit breaker está aberto ou quando a chamada falha. Pode ser um cache local, um valor padrão (como "serviço temporariamente indisponível") ou uma fila de retentativa. Nunca deixe o fallback vazio ou lançando exceção genérica. **Erro comum:** implementar fallback que chama outro serviço externo, criando um novo ponto de falha. O fallback deve ser autossuficiente, banco local, cache, ou resposta mock. ## Passo 6: Configurar o estado semiaberto e a recuperação Após o período de sleep, o circuit breaker entra em estado semiaberto e permite algumas requisições de teste. Se bem-sucedidas, o circuito fecha; se falharem, volta a abrir. Configure o número de chamadas de teste (geralmente 3 a 5) e o período de espera entre tentativas. **Dica:** monitore a taxa de sucesso no estado semiaberto. Se o serviço externo estiver degradado, mas não completamente fora, aumentar o número de chamadas de teste pode sobrecarregá-lo novamente. ## Passo 7: Expor métricas e logs para monitoramento Implemente endpoints de health check que mostrem o estado atual de cada circuit breaker (fechado, aberto, semiaberto). Use métricas como taxa de falha, número de chamadas rejeitadas e tempo médio de resposta. Ferramentas como Prometheus e Grafana ajudam a visualizar esses dados. **Erro comum:** não registrar logs quando o circuito abre. Sem logs, você descobre o problema apenas quando o usuário reclama. Log com nível WARN e o nome do serviço afetado. ## Passo 8: Testar a resiliência com caos controlado Simule falhas em ambiente de staging: derrube um serviço, aumente a latência artificialmente, varie o número de requisições. Verifique se o circuit breaker abre e fecha conforme configurado e se o fallback é acionado corretamente. Ferramentas como Chaos Monkey ou Toxiproxy ajudam a criar cenários realistas. **Dica:** comece com testes unitários que verificam a transição de estados. Depois, passe para testes de integração que simulam falhas reais de rede. ## Checklist do que foi implementado - [ ] Mapeamento de todas as chamadas remotas entre serviços - [ ] Biblioteca de circuit breaker escolhida e configurada - [ ] Threshold de falhas, timeout e sleep definidos com base em métricas - [ ] Código das chamadas remotas envolvido pelo padrão - [ ] Fallback implementado para cada endpoint crítico - [ ] Estado semiaberto configurado com número adequado de testes - [ ] Métricas e logs expostos para monitoramento - [ ] Testes de resiliência realizados em ambiente controlado ## Perguntas frequentes sobre circuit breaker em microservices ### Qual a diferença entre circuit breaker e retry? O retry tenta novamente a mesma chamada após uma falha, geralmente com backoff. O circuit breaker interrompe todas as chamadas por um período, protegendo o sistema de sobrecarga. Eles são complementares: use retry para falhas transitórias e circuit breaker para falhas persistentes. ### Devo usar circuit breaker em chamadas síncronas ou assíncronas? Ambas. Em chamadas síncronas, ele evita que threads fiquem bloqueadas esperando resposta. Em chamadas assíncronas (filas, eventos), ele impede que mensagens sejam enviadas a um serviço que não responde, reduzindo retrabalho. ### O circuit breaker funciona com serviços internos ou apenas externos? Funciona com qualquer chamada remota, seja entre serviços do mesmo ecossistema ou para APIs de terceiros. A decisão depende da criticidade e da latência esperada. Em chamadas internas com baixa latência, o overhead pode não valer a pena. ### Como escolher o threshold de falhas ideal? Baseie-se em métricas de produção: calcule a média de falhas em janelas de 1 minuto durante horários de pico. Defina o threshold como 2 a 3 desvios padrão acima dessa média. Ajuste gradualmente com base no comportamento observado. ### O que fazer quando o circuit breaker fica abrindo e fechando constantemente? Isso indica que o threshold está muito baixo ou o período de sleep muito curto. Aumente o número de falhas necessárias para abrir o circuito e estenda o sleep para pelo menos 30 segundos. Monitore se o serviço externo está realmente estável antes de reduzir os parâmetros. --- Fonte (canonical): https://blogsemjuizo.com.br/destaques/circuit-breaker-microservices-guia-de-implementacao-passo-a-passo/