Em uma arquitetura baseada em microsserviços, é comum que uma única requisição de usuário dispare uma cadeia de chamadas síncronas entre múltiplos serviços via HTTP/gRPC. Em cenários ideais, todas as dependências respondem em milissegundos. No entanto, em um ambiente distribuído, falhas de rede, lentidões de banco de dados e degradações de infraestrutura são inevitáveis.
Quando um serviço downstream (serviço B) fica lento ou para de responder, o serviço upstream (serviço A) continua enviando requisições e aguardando resposta até atingir o timeout. Esse comportamento prende threads de processamento e esgota conexões no serviço A. Rapidamente, a lentidão do serviço B contamina o serviço A e, sucessivamente, todo o ecossistema. Esse fenômeno é conhecido como Falha em Cascata (Cascading Failure) e pode derrubar um sistema inteiro devido a um problema pontual em um único componente secundário.
A Abordagem Tradicional: Retentativas Cegas (Naïve Retries) e Timeouts Fixos
Historicamente, a tentativa de resolver indisponibilidades temporárias entre serviços baseou-se em aplicar timeouts longos combinados com loops de retentativa imediata (retry) diretamente no cliente da requisição.
Ao receber um erro 500 ou um timeout, a aplicação tenta chamar o mesmo serviço afetado 3 ou 5 vezes consecutivas antes de devolver uma falha ao usuário.
Limitações das Retentativas Cegas
- Amplificação de Carga (Retry Storms): Se o serviço B está sobrecarregado (com CPU em 100%), receber centenas de retentativas adicionais por segundo impede completamente sua recuperação;
- Esgotamento de Threads: Conexões e recursos computacionais do chamador ficam retidos aguardando respostas de um serviço que comprovadamente está indisponível;
- Experiência do Usuário Degradada: O usuário final enfrenta uma tela de loading que demora dezenas de segundos para, no fim, resultar em uma página de erro genérica.
A Abordagem Moderna: Circuit Breaker Pattern
O padrão Circuit Breaker (Disjuntor) resolve esse problema atuando como um protetor elétrico em uma residência: se a corrente falha ou sobrecarrega a rede, o disjuntor “desarma” para interromper o fluxo e evitar danos maiores.
Em software, o Circuit Breaker é um componente que envolve as chamadas remotas. Ele monitora a taxa de falhas recentes e, ao detectar que um serviço dependente está instável, interrompe imediatamente as chamadas subsequentes por um período de tempo, retornando uma resposta de contingência (fallback) instantânea sem onerar a rede ou o serviço degradado.
Os Três Estados do Circuit Breaker
O mecanismo opera alternando dinamicamente entre três estados principais:
- Closed (Fechado – Fluxo Normal): O circuito permite que as requisições passem normalmente para o serviço dependente. Ele mede constantemente a taxa de sucessos e falhas dentro de uma janela de tempo.
- Open (Aberto – Falha Detectada): Quando a taxa de erros ultrapassa o limite configurado (ex: 50% de falhas em 10 segundos), o disjuntor “abre”. Qualquer nova chamada é bloqueada imediatamente no lado do cliente, executando a lógica de fallback sem realizar chamadas de rede.
- Half-Open (Meio-Aberto – Teste de Recuperação): Após um tempo de espera pré-determinado (ex: 30 segundos no estado Open), o disjuntor entra em Half-Open. Ele permite que um número limitado de requisições de teste passe para o serviço downstream:
- Se as requisições de teste obtiverem sucesso, o circuito assume que o serviço se recuperou e volta para o estado Closed.
- Se qualquer requisição de teste falhar, o circuito retorna imediatamente ao estado Open por mais um período.
Estratégias de Fallback (Contingência)
Quando o circuito está no estado Open, a aplicação deve fornecer um comportamento gracioso (Graceful Degradation) via lógica de fallback:
1. Resposta em Cache / Dados Padrão
Devolve informações previamente armazenadas em cache ou valores padrão estáticos (ex: se o serviço de recomendações falhar, exibe uma lista genérica dos produtos mais vendidos).
2. Degradação Funcional Graciosa
Desabilita temporariamente a funcionalidade secundária na interface sem interromper o fluxo principal (ex: permite que o usuário conclua a compra mesmo que o cálculo de pontos de fidelidade esteja fora do ar).
3. Fail Fast (Falha Rápida)
Devolve uma resposta clara e imediata de erro ao usuário (ex: HTTP 530 ou 429), evitando tempo de espera em tela.
Quando Utilizar Cada Abordagem?
- Utilize Retentativas Simples com Timeout curto quando: A chamada for idempotente e a falha for reconhecidamente um pequeno ruído de rede de frações de segundo.
- Utilize Circuit Breaker quando: A comunicação for síncrona entre microsserviços via HTTP/REST/gRPC e a indisponibilidade de um serviço dependente puder comprometer o restante do sistema.
- Combine Circuit Breaker + Bulkhead Pattern quando: O sistema operar em altíssima escala e for necessário isolar os pools de threads de cada dependência para que um circuito aberto não consuma recursos das chamadas saudáveis.
Na prática, ferramentas como Resilience4j, Istio Service Mesh e Envoy Proxy tornaram a implementação do Circuit Breaker indispensável para garantir a estabilidade global de arquiteturas distribuídas Cloud Native.
