O que é o Circuit Breaker?
Em poucas palavras é uma especie de disjuntor ou um design pattern criado para adicionar resiliência e tolerância a falhas de sistemas distribuídos. Ele atua como um proxy entre os serviço chamador e o serviço destino, impedindo que falhas em cascata derrubem toda a aplicação.
O Problema que ele Resolve?
Em arquitetura de microsserviços, quando um serviço A depende de um serviço B que fica indisponível, o serviço A começar a acumular threads bloqueadas aguardando respostas que nunca chegam. Isso leva a um esgotamento de recursos (resource exhaustion), que por sua vez torna também o serviço A indisponível, e assim a falha se propaga em efeito dominó por toda a aplicação. O Circuit Breaker resolve isso falhando rapidamente (fail fast) em vez de deixar a requisição travar por longos períodos.
Os Três Estados
| Estado | Comportamento | Transição |
|---|---|---|
| Closed (Fechado) | Requisições fluem normalmente; falhas são monitoradas | -> Open, quando o threshold de errors é atingindo |
| Open (Aberto) | Requisições são bloqueadas imediatamente; retorna fallback ou erro | -> Half-Open, após o timeout de recuperação |
| Half-Open (Meio-Aberto) | Um número limitado de requisições de testes é permitido | -> Closed (sucesso) ou Open (falha) |
No estado Closed, o sistema opera normalmente enquanto o circuit breaker monitora a taxa de erros. Se o número de falhas superar um threshold configurado (ex: 15 falhas em 60 segundos), ele transaciona para Open. Após um período de espera (cooling-off period), passa para Half-Open, onde permite algumas requisições de teste para verificar se o serviço se recuperou.
Benefícios e Desafios
Benefícios
- Previne falhas em cascata (cascading failures)
- Melhora a estabilidade geral do sistema ao reduzir a carga sobre serviços falhando
- Fornece insights sobre a saúde e confiabilidade dos serviços
Desafios
- Configurar os thresholds e timeouts ideais exige conhecimento profundo do comportamento dos serviços
- Requer estratégias de fallback bem definidas
- O padrão assume que o serviço se recupera com o tempo o que nem sempre é verdade
Quando Usar
- Chamadas síncronas entre microsserviços
- Integrações com APIs externas ou de terceiros
- Serviços com alto risco de sobrecarga ou latência variável
- Ambiente de alta disponibilidade onde downtime é crítico