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.