- Use circuit breaker quando a API oscila e o retry vira prejuízo
- Defina 3 estados: fechado (normal), aberto (bloqueia), meio-aberto (testa)
- O sinal de abertura pode ser taxa de erro, sequência de 429/5xx, timeout ou latência anormal
- Circuit breaker não substitui fila/DLQ: ele evita o colapso; a fila segura o trabalho
- Precisa de alerta: breaker aberto sem notificação vira “silêncio” operacional
1) Identifique onde dói: qual integração provoca cascata
Liste os pontos onde uma falha externa vira dominó (ex.: WhatsApp API, CRM, ERP, gateway de e-mail). Procure sintomas: muitos retries, execuções longas, aumento de custo por operação, backlog, ou duplicação de pedidos. Se a falha de um fornecedor derruba dezenas de fluxos, você tem um bom candidato.
2) Defina critérios de abertura (gatilhos) e janela
Escolha uma métrica simples que você consegue medir no próprio fluxo: contagem de erros em uma janela (ex.: últimos N eventos), sequência de falhas (ex.: 10 falhas seguidas), ou tipos de erro (429 rate limit, 5xx, timeout). Evite overengineering: comece com sequência de falhas + cooldown (tempo aberto). Se você não tiver o número ideal, use um valor conservador e ajuste com logs.
3) Modele os estados: fechado, aberto e meio-aberto
Fechado: segue chamando a API normalmente. Aberto: bloqueia novas chamadas para aquela integração e manda para uma rota de fallback (fila, log, notificação, “aguarde”). Meio-aberto: após o cooldown, permita 1 ou poucos testes; se passar, feche; se falhar, reabra e estenda o cooldown.
4) Crie um “check” no início do fluxo (guard clause)
Antes do nó que chama a API, consulte um armazenamento de estado do breaker (banco, Redis, Data Store, planilha, KV interno). Se estado = aberto e ainda dentro do cooldown, não chame a API. Em n8n, isso costuma ser um IF + consulta em Postgres/Redis/Static Data; no Make, um Data Store/variable + Router; no Zapier, Paths + Storage (dependendo do plano) ou um passo de Webhook consultando seu KV.
5) Registre falhas e successes com idempotência
Ao capturar um erro, incremente contador e carimbe timestamp. Ao capturar sucesso, zere contador e atualize “lastSuccess”. Cuide para não contar duas vezes o mesmo evento (idempotência): guarde um eventId (pedidoId, messageId, leadId) e ignore reprocessamentos.
6) Defina o fallback: enfileirar, adiar ou degradar a experiência
Circuit breaker sem fallback vira perda de dado. Escolha: (a) enfileirar para reprocessar depois; (b) agendar tentativa futura; (c) degradar (ex.: salvar lead e notificar equipe, em vez de sincronizar no CRM). Para automações críticas, combine com fila e uma rota de reprocessamento.
7) Alerta e observabilidade: breaker aberto tem que gritar
Quando abrir, dispare notificação (Slack/WhatsApp/e-mail) com: integração afetada, erro mais comum, tempo de cooldown, volume impactado. Salve um log estruturado. Sem isso, o time só descobre horas depois quando alguém reclama.
8) Teste em caos controlado e ajuste thresholds
Simule 429/500/timeouts (até com um endpoint de teste) e confirme: o fluxo para de martelar a API, o fallback recebe eventos, e o breaker volta ao normal após estabilizar. Ajuste limiar e cooldown para evitar flapping (abre/fecha toda hora).
Quando circuit breaker vale mais do que “só colocar retry”
Retry é ótimo para falhas transitórias — até o dia em que o fornecedor cai de verdade ou começa a devolver 429 por minutos. Aí o retry vira amplificador: mais chamadas, mais bloqueio, mais filas, mais custo e mais chance de duplicar ações.
Circuit breaker é o freio de emergência: ele aceita que, por um período, a integração está ruim e protege o restante da operação.
- Use quando: 429 frequente, 5xx em ondas, timeouts, instabilidade de DNS, quedas do provedor.
- Evite usar quando: o erro é “dados inválidos” (4xx por payload errado). Aí você precisa corrigir o dado, não abrir breaker.
- Sinal clássico: o tempo de execução do fluxo sobe e o backlog cresce mais rápido do que você consegue processar.
Modelo simples (e bom) de circuit breaker para automações
Você não precisa de uma biblioteca sofisticada para ter o efeito prático. O essencial é guardar estado e ter uma regra clara de bloqueio.
| Estado | O que o fluxo faz | Quando entra | Quando sai |
|---|---|---|---|
| Fechado (Closed) | Chama a API normalmente | Padrão inicial | Sai se bater o limiar de falhas |
| Aberto (Open) | Não chama a API; manda para fallback | Após N falhas (ou taxa de erro na janela) | Sai após cooldown, indo para Meio-aberto |
| Meio-aberto (Half-open) | Permite 1 ou poucos testes | Após cooldown do Aberto | Fecha com sucesso; reabre com falha |
Como implementar na prática no n8n (sem depender de mágica)
No n8n, a forma mais previsível é: guardar o estado do breaker em um lugar compartilhado (Postgres/Redis), consultar no início do fluxo e atualizar no tratamento de erro/sucesso.
Padrão de blocos que costuma funcionar bem:
- Entrada (Webhook/Cron/Queue) → Buscar estado do breaker (DB/Redis) → IF estado=Open e agora
- Rota Normal → Chamada da API → Se sucesso: reset contador + lastSuccess
- Se erro: incrementar contador; se contador>=limiar → set Open com openUntil=agora+cooldown; logar + alertar
- Rota Fallback → persistir evento para reprocessar (fila/tabela) + notificar (dependendo da criticidade)
Como adaptar no Make e no Zapier (onde o estado é o desafio)
Em plataformas mais “cenário-a-cenário”, o ponto crítico é o armazenamento de estado. Se você não tiver um Data Store/KV fácil, dá para usar um banco externo (Supabase/Postgres/Redis) ou um endpoint simples que responda o estado do breaker.
O desenho mental é o mesmo: um passo inicial consulta estado → Router/Paths decide → passos finais atualizam estado.
- Make: Router com rota 'Open' e 'Normal'; Data Store/DB para openUntil e contador; tratamento de erro para atualizar contagem.
- Zapier: Paths (A/B) + Storage (quando disponível) ou Webhooks consultando um KV; atenção para limites de retries e execução por tarefa.
- Dica prática: se a automação dispara por eventos muito frequentes, prefira estado em Redis/Postgres para evitar corrida e inconsistência.
Armadilhas comuns (onde muita automação “bonita” quebra)
Circuit breaker mal desenhado cria dois problemas: (1) bloqueia coisa demais (falso positivo) e (2) não bloqueia o suficiente (abre tarde).
- Contar erro de validação como falha do fornecedor: separar 4xx por payload de 429/5xx/timeout.
- Não ter idempotência: reprocessamento vira duplicação (pedido duplicado, mensagem duplicada, cobrança duplicada).
- Cooldown curto demais: flapping (abre/fecha toda hora) e o time perde confiança.
- Sem alerta: breaker aberto vira apagão silencioso.
- Sem fallback persistente: você ‘protege’ a API, mas perde o evento.
Perguntas frequentes
Circuit breaker é a mesma coisa que retry com backoff?
Qual métrica eu uso para abrir o circuit breaker se eu não tenho observabilidade boa?
Circuit breaker funciona para WhatsApp API e provedores que dão 429?
Eu preciso de fila (RabbitMQ/SQS/Redis Streams) para usar circuit breaker?
Leia também
Rate limit, retry e backoff: como parar de quebrar automação em API (n8n, Make, Zapier)
Guia direto para lidar com rate limit (429), retries e backoff em automações com APIs. Aprenda padrões práticos para n8n, Make e Zapier e evite falhas intermitentes, duplicidades e banimentos.
Ler →
Como desenhar uma arquitetura de automação com filas, retry e idempotência (sem virar gambiarra)
Guia prático para desenhar automações resilientes: quando usar filas, como fazer retry/backoff, idempotência e DLQ. Evite duplicar pedidos, estourar rate limit e cair em loop infinito em n8n/Make/Zapier.
Ler →
Como usar Dead Letter Queue (DLQ) em automações: trate falhas sem perder eventos
Guia prático de Dead Letter Queue (DLQ) para automações: quando usar, como modelar eventos, reprocessar com segurança e evitar duplicidade em n8n/Make/Zapier.
Ler →
n8n vs Make para workflows long-running: filas, retries e tarefas que não podem falhar
Entenda qual ferramenta lida melhor com automações longas (minutos/horas), filas, rate limit e reprocessamento: n8n ou Make. Comparação prática com cenários reais no Brasil.
Ler →