quarta-feira, 09 de setembro de 2026 · Edição online
PosUp
PosUp

Circuit Breaker Padroes: 9 Formas de Evitar Falhas em Cascata

ResumoCircuit Breaker Patterns são estratégias de engenharia de software para prevenir falhas em cascata em sistemas distribuídos. Esses padrões interrompem chamadas a serviços instáveis, permitindo degradação graciosa e recuperação rápida. As 9 abordagens variam entre estados fechado, aberto e meio-aberto, com políticas de timeout, retry e monitoramento. A seleção correta depende da latência tolerável, da criticidade do serviço e do orçamento de recursos disponíveis.

Falhas em cascata derrubam sistemas inteiros por causa de um unico servico lento. Os padroes de circuit breaker resolvem isso. Veja 9 abordagens e como escolher a certa.

Patrícia Lemos Patrícia Lemos · Especialista em dados e analytics
· · 6 min de leitura
Circuit Breaker Padroes: 9 Formas de Evitar Falhas em Cascata
Foto: Imagem ilustrativa · PosUp

Falhas em cascata derrubam sistemas inteiros por causa de um unico servico lento. Os padroes de circuit breaker resolvem isso. Veja 9 abordagens e como escolher a certa.

Falhas em cascata acontecem quando um servico lento ou indisponivel faz outros esperarem, consumindo recursos ate derrubar o sistema inteiro. O padrao circuit breaker age como um disjuntor eletrico: quando a falha atinge um limite, ele interrompe a chamada e protege o resto da arquitetura. Abaixo, 9 padroes que implementam essa ideia na pratica.

1. Circuit Breaker com estados fechado, aberto e meio-aberto

E a base de todos os padroes. No estado fechado, as chamadas passam normalmente. Quando o numero de falhas ultrapassa o limite configurado, o circuito abre e as chamadas falham rapidamente, sem esperar timeout. Depois de um tempo de espera, o circuito entra em meio-aberto: permite algumas chamadas de teste. Se passarem, fecha novamente; se falharem, abre outra vez.

O criterio para usar este padrao e simples: voce precisa de um limite claro de falhas e um tempo de reset. Por exemplo, abrir apos 5 falhas consecutivas e testar apos 30 segundos. Sem esses numeros, o circuito nunca decide.

2. Timeout por chamada, antes do circuit breaker

Muitas falhas em cascata comecam com timeouts longos. Um servico que demora 10 segundos para responder segura threads e conexoes. O timeout por chamada, com valor menor que o tempo de resposta esperado, evita que o recurso fique preso.

A pergunta que esse numero responde: quanto tempo sua chamada pode esperar sem travar o resto? Se o servico normalmente responde em 200ms, um timeout de 2 segundos ja e generoso. Ajuste com base no percentil 95 de latencia, nao na media.

3. Retry com limite e backoff exponencial

Repetir uma chamada que falhou pode resolver problemas temporarios, mas sem limite vira amplificador de carga. O padrao retry com backoff exponencial aumenta o intervalo entre tentativas, dando tempo ao servico para se recuperar.

O detalhe importante: nunca use retry em chamadas que nao sao idempotentes. Se a primeira tentativa processou o pedido e a resposta se perdeu, repetir pode duplicar a operacao. Limite a 2 ou 3 tentativas, no maximo.

4. Bulkhead: isolar falhas por recurso

O padrao bulkhead divide os recursos em compartimentos separados. Em vez de um pool de conexoes unico para todos os servicos, cada um tem seu proprio pool limitado. Se um servico consome todas as conexoes do seu compartimento, os outros continuam funcionando.

O criterio de decisao e o impacto: qual servico, se falhar, nao pode derrubar os demais? Separe por criticidade ou por tipo de dependencia. O custo e maior utilizacao de memoria, mas a isolacao compensa em sistemas com dependencias heterogeneas.

5. Fallback com resposta padrao ou dado em cache

Quando o circuito abre, em vez de retornar erro, voce entrega uma resposta alternativa. Pode ser um dado em cache, uma versao simplificada ou uma mensagem de indisponibilidade. O usuario nao ve a falha, ve uma experiencia degradada.

O exemplo concreto: um servico de recomendacoes que falha pode retornar os produtos mais vendidos do dia, salvos em cache. A decisao e de negocio: o que e aceitavel mostrar quando o dado fresco nao esta disponivel? Sem fallback, o circuito so troca uma falha por outra.

6. Rate limiting no client, para evitar sobrecarga

O circuit breaker protege contra falhas, mas o rate limiting protege contra voce mesmo. Se um cliente faz 1000 requisicoes por segundo a um servico que aguenta 500, o servico vai falhar. Limitar a taxa no lado do cliente evita que o problema comece.

O numero aqui e a capacidade do servico, que voce precisa conhecer ou estimar com testes de carga. Sem esse dado, o limite e arbitrario. Uma abordagem pratica: comecar conservador e aumentar gradualmente observando a latencia.

7. Circuit breaker por dependencia, nao global

Um circuito unico para todas as chamadas externas e grosseiro. Se um servico de pagamento falha, nao faz sentido bloquear tambem o servico de catalogo. O padrao por dependencia cria um circuit breaker para cada servico ou grupo de servicos.

O criterio e a autonomia: cada dependencia tem seus proprios limites de falha e tempo de reset. Isso permite que o sistema continue operando parcialmente, em vez de cair por inteiro. Vale o esforco extra de configuracao.

8. Circuit breaker por rota ou endpoint

Dentro de um mesmo servico, endpoints diferentes tem comportamentos diferentes. O endpoint de consulta pode ser estavel, enquanto o de gravacao falha. Separar o circuito por rota permite tratar cada caso com limites especificos.

O exemplo: um endpoint que faz integracao com banco pode falhar por lock, enquanto o de leitura em cache responde bem. Com circuitos separados, a leitura continua funcionando durante a falha de gravacao. A granularidade custa mais monitoramento, mas melhora a disponibilidade.

9. Circuit breaker com monitoramento e alertas

Nenhum padrao funciona sem visibilidade. O circuit breaker precisa expor metricas: quantas vezes abriu, quanto tempo ficou aberto, quantas chamadas foram rejeitadas. Esses dados alimentam alertas e decisoes de ajuste.

A pergunta que esses numeros respondem: o circuito esta protegendo ou escondendo um problema recorrente? Se abre com frequencia, o servico dependente precisa de correcao, nao de mais tolerancia. Monitore a taxa de abertura e o impacto no usuario.

Como escolher o padrao certo

Nao existe um padrao unico que resolva tudo. Comece com timeout e circuit breaker por dependencia, que cobrem a maioria dos casos. Adicione bulkhead se ha dependencias criticas que precisam de isolamento. Use fallback quando a experiencia degradada for aceitavel. Rate limiting e essencial se voce controla o cliente.

A ordem pratica: implemente o basico, meca as aberturas de circuito e ajuste os limites com dados reais. Um circuito que nunca abre pode estar mal configurado; um que abre toda hora indica problema maior na dependencia.

FAQ

O que e o padrao circuit breaker?

E um padrao de resiliencia que interrompe chamadas a um servico instavel apos um limite de falhas. Ele evita que um servico lento ou indisponivel cause falhas em cascata, protegendo os recursos do sistema.

Qual a diferenca entre circuit breaker e retry?

Retry repete chamadas que falharam, assumindo que a falha e temporaria. Circuit breaker para de chamar por um periodo, assumindo que o servico precisa de tempo para se recuperar. Na pratica, o retry deve ter limite e o circuit breaker deve controlar o fluxo.

Quando o circuit breaker deve abrir?

Quando o numero de falhas consecutivas ou a taxa de erro ultrapassa um limite configurado. O valor depende da tolerancia do sistema e do impacto no usuario. Uma boa pratica e basear no percentil de latencia e na taxa de erro observada.

O que e o estado meio-aberto no circuit breaker?

E o estado entre aberto e fechado, onde o circuito permite um numero limitado de chamadas de teste. Se elas passam, o circuito fecha; se falham, abre novamente. Isso evita que o servico receba carga total antes de estar realmente recuperado.

Circuit breaker funciona so para microsservicos?

Nao. O padrao se aplica a qualquer chamada remota: APIs, bancos de dados, filas, servicos externos. Em arquiteturas monoliticas com integracoes externas, ele tambem protege contra falhas de dependencias.

Como definir os limites do circuit breaker?

Observe o comportamento normal do servico: latencia media, taxa de erro e tempo de recuperacao. Configure o limite de falhas e o tempo de reset com base nesses dados. Ajuste continuamente conforme o sistema evolui.

Compartilhar:
Patrícia Lemos

Patrícia Lemos

Especialista em dados e analytics

Transforma painel cheio de número em decisão. Cuida de mensuração, dashboard e a métrica que de fato move o negócio.

Ver todos os artigos →

Leia também

Distributed tracing vs centralized logging: qual usar primeiro?
Apps e Software

Distributed tracing vs centralized logging: qual usar primeiro?

Distributed tracing e centralized logging atacam problemas diferentes. Saiba qual implementar primeiro para reduzir o tempo de diagnóstico e o custo de infraestrutura na sua operação.

09 de setembro de 2026 · Rodrigo Salles
Memory Leak Diagnóstico: Guia Prático em Produção
Apps e Software

Memory Leak Diagnóstico: Guia Prático em Produção

Diagnosticar memory leak em produção não precisa ser um bicho de sete cabeças. Com o processo certo, você identifica a causa raiz e resolve antes que o sistema caia. Veja o passo a passo.

09 de setembro de 2026 · Patrícia Lemos
Rate Limiting em APIs: o que é e como protege seu sistema
Apps e Software

Rate Limiting em APIs: o que é e como protege seu sistema

Rate limiting controla quantas requisições um cliente pode fazer a uma API em um intervalo de tempo. Sem ele, seu serviço fica exposto a sobrecarga, ataques e custos imprevisíveis. Veja como funciona e como aplicar.

09 de setembro de 2026 · Patrícia Lemos

Gostou? Receba mais análises

Newsletter quinzenal · curadoria editorial · sem spam