# Saga Pattern vs Two-Phase Commit: Quando Usar Cada Um

> Saga Pattern é um padrão de transações distribuídas que divide operações em etapas locais com compensações em caso de falha, priorizando disponibilidade e baixo acoplamento. Two-Phase Commit (2PC) coordena transações distribuídas com bloqueio síncrono e consistência forte, mas reduz disponibilidade. Saga Pattern é indicado para microsserviços e fluxos longos; 2PC, para transações curtas que exigem atomicidade estrita.

*Blog Sem Juízo · Especiais · 10 de setembro de 2026 · Tomás Wenzel*

Saga Pattern ou Two-Phase Commit? A escolha define se seu sistema distribuído trava ou segue fluido. Neste comparativo, mostro como cada um lida com falhas, consistência e acoplamento, e em qual situação cada padrão realmente vale a pena.

Saga Pattern ou Two-Phase Commit? Essa pergunta aparece sempre que um sistema distribuído precisa manter dados coerentes entre serviços. A resposta curta: use Saga quando prioriza disponibilidade e baixo acoplamento; use Two-Phase Commit (2PC) quando a atomicidade forte é obrigatória e o número de participantes é pequeno. O resto é consequência.

Saga Pattern é preferível em microsserviços com consistência eventual e alta disponibilidade, pois usa transações locais e compensações. Two-Phase Commit garante atomicidade forte, mas acopla serviços e bloqueia recursos, sendo ideal apenas quando consistência imediata é inegociável e a escala é controlada.

## Consistência: forte ou eventual?

A diferença começa aqui. No 2PC, todos os participantes precisam confirmar a transação antes que qualquer um efetive a mudança. É o clássico "tudo ou nada". Se um nó falha, os demais ficam bloqueados esperando a decisão do coordenador. Já a Saga divide a operação em etapas locais. Cada serviço commita sua parte e, se algo dá errado depois, dispara uma ação compensatória (estorno, cancelamento, reversão). O resultado é consistência eventual: o sistema converge para o estado correto, mas não instantaneamente.

Um exemplo: num e-commerce, 2PC travaria o estoque até o pagamento confirmar. Na Saga, o estoque é reservado, o pagamento processado e, se falhar, a reserva é desfeita. O cliente vê a confirmação um pouco depois, mas o sistema não trava.

## Acoplamento e arquitetura

2PC exige que todos os serviços envolvidos falem o mesmo protocolo e estejam disponíveis durante a transação. Isso cria um acoplamento temporal forte: se um cair, os outros sentem. Em arquiteturas de microsserviços, onde cada time evolui seu serviço de forma independente, esse modelo vira um gargalo organizacional.

A Saga inverte a lógica. Cada serviço expõe uma operação local e reage a eventos. O acoplamento é fraco, geralmente via mensageria (Kafka, RabbitMQ). A contrapartida é que a lógica de compensação precisa ser desenhada com cuidado. Não existe almoço grátis: você troca o bloqueio do 2PC pela complexidade de orquestrar falhas parciais.

## Performance e escalabilidade

2PC segura locks durante toda a transação. Em cenários com muitos participantes ou latência alta entre datacenters, o tempo de bloqueio cresce e a vazão despenca. Um coordenador sobrecarregado vira ponto único de falha. Por isso, 2PC costuma funcionar bem em ambientes controlados, com poucos nós e rede rápida.

Saga não mantém locks globais. Cada passo é uma transação local curta, o que favorece paralelismo e escala horizontal. O custo aparece na latência total: como as etapas são sequenciais ou coreografadas, o tempo até a consistência final pode ser maior. Em sistemas que exigem resposta imediata, isso pesa.

## Complexidade de implementação

Implementar 2PC é relativamente direto quando se usa um gerenciador de transações pronto (como o do XA). A parte difícil é garantir que todos os participantes suportem o protocolo e que o coordenador seja resiliente.

Saga exige mais trabalho de design. Você precisa definir compensações para cada passo, lidar com idempotência, evitar loops de retry e monitorar transações em andamento. Ferramentas como Temporal, Camunda ou Axon ajudam, mas não eliminam a necessidade de entender o fluxo. É mais código, mais testes, mais observabilidade.

## Quando usar cada um (tabela comparativa)

| Critério | Two-Phase Commit | Saga Pattern | |----------|------------------|--------------| | Consistência | Forte (atômica) | Eventual | | Acoplamento | Alto (temporal) | Baixo (via eventos) | | Bloqueio de recursos | Sim, durante toda a transação | Não, apenas transações locais | | Escalabilidade | Limitada | Alta | | Complexidade | Média (com XA) | Alta (compensações, idempotência) | | Tolerância a falhas | Baixa (coordenador é ponto único) | Alta (serviços independentes) | | Ideal para | Monolitos distribuídos, poucos participantes, consistência imediata | Microsserviços, muitos participantes, disponibilidade |

## Veredito: escolha pelo contexto, não por moda

Para quem busca consistência forte e imediata, com poucos serviços e ambiente controlado, o Two-Phase Commit ainda é a escolha certa. Pense em sistemas financeiros tradicionais, onde cada centavo precisa ser debitado e creditado na mesma transação.

Para quem busca escalabilidade, resiliência e baixo acoplamento em microsserviços, a Saga Pattern é o caminho. Aceite a consistência eventual e invista em compensações bem testadas. É o preço da flexibilidade.

Não existe bala de prata. O erro comum é tentar aplicar 2PC em arquiteturas que não foram feitas para ele, ou usar Saga onde a atomicidade é inegociável. Avalie o custo de uma inconsistência temporária: se for tolerável, Saga; se não, 2PC.

## FAQ

### O que é Two-Phase Commit?

É um protocolo de transação distribuída que coordena múltiplos participantes em duas fases: preparação e commit. Todos os nós devem confirmar que estão prontos antes de qualquer um efetivar a mudança. Garante atomicidade, mas bloqueia recursos e exige coordenação central.

### O que é Saga Pattern?

É um padrão que divide uma transação distribuída em uma sequência de transações locais. Cada serviço executa sua parte e, em caso de falha, dispara ações compensatórias para desfazer o que foi feito. Oferece consistência eventual e baixo acoplamento.

### Qual a principal diferença entre Saga e 2PC?

A consistência. 2PC garante atomicidade forte e imediata, mas bloqueia recursos e acopla serviços. Saga prioriza disponibilidade e escalabilidade, aceitando consistência eventual e usando compensações para lidar com falhas parciais.

### Quando evitar o Two-Phase Commit?

Evite 2PC em microsserviços com muitos participantes, alta latência entre nós ou necessidade de escala horizontal. O bloqueio de recursos e o acoplamento temporal podem degradar a performance e criar pontos únicos de falha.

### Saga Pattern pode substituir 2PC em todos os casos?

Não. Se o sistema exige consistência imediata e não tolera estados intermediários, 2PC ainda é necessário. Saga é indicada quando a consistência eventual é aceitável e a prioridade é resiliência e escalabilidade.

### Como implementar compensações na Saga?

Cada passo da Saga precisa de uma ação compensatória idempotente que reverta seu efeito. Por exemplo, se o pagamento falha, a reserva de estoque deve ser cancelada. Ferramentas como Temporal e Camunda ajudam a orquestrar essas compensações, mas o design é responsabilidade do time.

---

Fonte (canonical): https://blogsemjuizo.com.br/especiais/saga-pattern-vs-two-phase-commit-quando-usar-cada-um/