O que é o Saga Pattern (sem a parte acadêmica)
Quando uma automação mexe em um único sistema (ou num único banco), você às vezes consegue “ou vai tudo, ou não vai nada”. Só que, no mundo real, a automação atravessa checkout, ERP, gateway de pagamento, CRM, WhatsApp, e-mail, planilha… e cada um tem suas regras, limites e tempo de resposta.
O Saga Pattern é uma forma prática de lidar com isso: você assume que falhas vão acontecer e desenha o processo como uma sequência de passos independentes. Para cada passo crítico, você define o que fazer se precisar “desfazer” (compensar) porque algo que vem depois deu errado.
Saga não é retry: é estratégia de consistência
Retry (tentar de novo) resolve falha temporária. Saga resolve falha lógica/operacional quando a automação já alterou o mundo: emitiu nota, criou pedido, reservou estoque, disparou mensagem. Se você só der retry, pode duplicar ou piorar o problema.
Na prática, Saga trabalha com duas ideias: (1) cada etapa deixa rastros e (2) existe um caminho de compensação para voltar a um estado aceitável, mesmo que não seja “perfeito” como uma transação única.
- Retry: “falhou porque deu 429/timeout, tenta de novo depois”.
- Saga: “falhou depois de cobrar; agora preciso estornar e marcar o pedido como cancelado/pendente”.
- Idempotência: “se eu rodar duas vezes, não crio dois pedidos” (Sagas quase sempre precisam disso).
Quando vale a pena usar Saga em automações (e quando é overkill)
Você não precisa chamar tudo de Saga. O padrão faz diferença quando o custo do erro é alto e o fluxo tem pontos sem volta (ou difíceis de reverter).
| Cenário | Sem Saga costuma dar ruim como? | Com Saga, o que muda? |
|---|---|---|
| E-commerce: pedido → cobrança → ERP → envio | Cobrou, mas ERP falhou; estoque fica travado ou pedido fica “fantasma” | Compensa: estorno/liberação de estoque + reprocesso controlado |
| Onboarding B2B: criar empresa → usuários → permissões → cobrança | Conta criada pela metade; suporte vira “mutirão” | Compensa: desativar empresa/usuários ou voltar para estado “rascunho” |
| WhatsApp: disparo em lote com atualizações no CRM | Mensagem enviada mas CRM não marca; time perde histórico | Compensa: re-sync do status ou fila de reconciliação |
| Automação simples: copiar linha da planilha → criar tarefa | Baixo impacto; dá para reexecutar manualmente | Saga geralmente é exagero (um bom log + retry já resolve) |
Os dois sabores de Saga: orquestrada vs coreografada
Em automação de workflows, o mais comum é a Saga orquestrada: um único fluxo central decide a ordem, registra estado e dispara compensações. A coreografada (eventos entre serviços) aparece mais em arquitetura de microsserviços, mas dá para imitá-la com filas e eventos.
| Tipo | Como funciona | Bom para | Ponto de atenção |
|---|---|---|---|
| Orquestrada | Um workflow central coordena passos e compensações | n8n/Make/Zapier com múltiplas integrações | Evitar virar “monolito de automação” sem observabilidade |
| Coreografada | Cada sistema reage a eventos e dispara o próximo | Times com stack de eventos/filas | Debug é mais difícil; exige rastreio e correlação |
Como desenhar uma Saga na prática (checklist que evita dor)
O erro mais comum é pensar na compensação só depois que dá problema. Em Saga, você desenha ida e volta desde o início.
- Defina o objetivo final do processo (o “estado desejado”).
- Quebre em etapas com efeitos observáveis (o que muda em cada sistema).
- Para cada etapa, escreva a compensação possível (estornar, cancelar, liberar, desativar, marcar como pendente).
- Registre um ID de correlação em tudo (pedidoId, leadId, protocolId) para rastrear e deduplicar.
- Armazene estado do workflow (ex.: “PASSO_3_CONCLUIDO”) para saber onde retomar.
- Defina quais erros são retry e quais disparam compensação imediatamente.
- Planeje reconciliação: um job/fluxo que varre pendências e conserta inconsistências (porque compensação nem sempre é instantânea).
Exemplo mental (bem Brasil): cobrança via Pix e entrega
Imagine um fluxo: (1) criar pedido no ERP, (2) gerar cobrança Pix, (3) confirmar pagamento, (4) criar expedição e etiqueta, (5) avisar cliente no WhatsApp.
Se der erro no passo 4 depois de confirmado o pagamento, não adianta só “tentar de novo” para sempre. Você precisa de uma regra: expedição falhou por X tempo? Compensa com reembolso ou manda para fila manual com SLA e alerta. Isso é Saga: o processo tem saída controlada para não virar um limbo.
Armadilhas comuns ao tentar aplicar Saga em ferramentas de automação
Ferramentas de automação ajudam muito, mas têm limitações: execução pode expirar, webhooks podem duplicar, APIs podem negar por rate limit e algumas ações não têm “desfazer” oficial.
- Compensação impossível: você dispara um e-mail irreversível; a compensação vira “enviar outro e-mail corrigindo” (ok, mas seja explícito).
- Falta de idempotência: compensação roda duas vezes e cria um segundo estorno/ticket.
- Sem DLQ/fila de quarentena: erro repetido fica batendo na mesma parede e polui logs.
- Estado solto: sem persistir etapas concluídas, você não sabe se deve retomar ou compensar.
Perguntas frequentes
Saga Pattern é a mesma coisa que transação distribuída (2PC)?
Preciso ter compensação para todos os passos?
Se eu tiver idempotência, ainda preciso de Saga?
Como eu sei que estou exagerando (overengineering)?
Termos relacionados
Como fazer idempotência em automações com webhook (e parar de duplicar pedidos, notas e leads)
Guia direto para aplicar idempotência em automações com webhook: chaves idempotentes, deduplicação, banco/planilha, retries e boas práticas para 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 →
Circuit breaker em automações (n8n/Make/Zapier): como evitar cascata de erros quando uma API cai
Guia prático para aplicar padrão circuit breaker em automações no n8n, Make ou Zapier: quando abrir/fechar, como detectar falhas, fallback, filas e alertas para não derrubar sua operação.
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 →