Circuit Breaker: como implementar em microsservicos (guia)

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.