Circuit breaker em microservices: guia prático de implementação

Implementar circuit breaker em microservices evita que uma falha em um serviço derrube toda a cadeia de chamadas. Você vai aprender, na prática, como proteger seus serviços com esse padrão de projeto, usando bibliotecas consolidadas e sem reinventar a roda.

Pré-requisitos: conhecimento básico de microservices, um serviço com dependências externas (HTTP, banco, fila) e acesso a uma biblioteca de resiliência, como Resilience4j (Java) ou Polly (.NET). O resultado esperado: chamadas a serviços instáveis são interrompidas rapidamente, liberando recursos e dando tempo para a recuperação.

Passo 1: Identifique os pontos de falha

Mapeie as chamadas remotas que podem falhar: APIs externas, bancos de dados, mensageria. Liste cada dependência e o impacto de sua indisponibilidade. Erro comum: proteger apenas as chamadas mais óbvias e esquecer as internas. Dica: comece pelos serviços com maior latência ou histórico de instabilidade.

Passo 2: Escolha a biblioteca e configure os limiares

Adote uma biblioteca madura, como Resilience4j, que oferece circuit breaker com configuração declarativa. Defina três parâmetros essenciais: taxa de falha (ex.: 50%), volume mínimo de chamadas (ex.: 10) e janela de tempo (ex.: 30 segundos). Erro comum: copiar configurações da internet sem ajustar à sua realidade. Dica: monitore a latência real do serviço antes de fixar os números.

Passo 3: Implemente os estados do circuit breaker

O padrão usa três estados: fechado (chamadas passam normalmente), aberto (falhas acima do limiar, chamadas são rejeitadas imediatamente) e meio-aberto (após um tempo de espera, permite um teste). Configure o timeout de espera no estado aberto, geralmente entre 5 e 15 segundos. Erro comum: não testar o cenário de recuperação. Dica: simule a falha em ambiente de staging e verifique a transição de estados.

Passo 4: Defina fallbacks e registre métricas

Para cada chamada protegida, crie um fallback: um valor padrão, um cache ou uma mensagem de erro amigável. Exponha métricas do circuit breaker (estado atual, contagem de falhas, chamadas rejeitadas) em um dashboard. Erro comum: deixar o fallback genérico, que mascara o problema. Dica: use o fallback para retornar dados parciais, não para silenciar erros.

Passo 5: Teste e monitore em produção

Faça testes de caos: derrube um serviço dependente e observe o comportamento do circuit breaker. Monitore os logs e as métricas para ajustar os limiares. Erro comum: acreditar que a configuração inicial é definitiva. Dica: revise os parâmetros a cada mudança de tráfego ou de infraestrutura.

Checklist final

Você identificou os pontos de falha, escolheu a biblioteca, configurou os limiares, implementou os estados, criou fallbacks e está monitorando as métricas. Falta apenas documentar as decisões e compartilhar com o time. Em seguida, considere adicionar retry com backoff e timeout por chamada para completar a estratégia de resiliência.

FAQ

O que é circuit breaker em microservices?

É um padrão de projeto que monitora chamadas a serviços remotos e interrompe temporariamente novas chamadas quando a taxa de falhas ultrapassa um limite. Isso evita que um serviço lento ou indisponível consuma recursos e cause falhas em cascata.

Quando o circuit breaker é acionado?

Ele é acionado quando a taxa de falhas atinge o limiar configurado, dentro da janela de tempo. No estado aberto, as chamadas são rejeitadas imediatamente, sem tentar a conexão. Após um período, ele passa para meio-aberto e testa uma chamada.

Qual biblioteca usar para circuit breaker?

Resilience4j é uma opção leve para Java, com configuração via código ou anotações. Para .NET, Polly é amplamente usada. Ambas oferecem circuit breaker, retry e timeout, e integram-se a frameworks como Spring Boot e ASP.NET Core.

Circuit breaker é igual a retry?

Não. Retry tenta novamente a mesma chamada após uma falha, o que pode piorar a sobrecarga. Circuit breaker interrompe as chamadas por um período, dando espaço para o serviço se recuperar. Eles são complementares, mas devem ser usados com critério.

Como testar circuit breaker em produção?

Use testes de caos, como derrubar um serviço dependente em ambiente de staging ou usar ferramentas de injeção de falhas (ex.: Chaos Monkey). Monitore as métricas e os logs para validar a transição de estados e os fallbacks.

O que acontece se o circuit breaker ficar sempre aberto?

Isso indica que o serviço dependente está permanentemente instável. Revise os limiares e o fallback. Se o problema persistir, investigue a causa raiz do serviço e considere uma abordagem de degradação gradual ou cache mais robusto.