The Two-Phase Commit protocol(2PC) has long been the standard for ensuring atomicity across distributed transactions. It guarantees that all participants in a transaction either commit together or abort together, maintaining strict consistency across multiple services. However, this guarantee comes with a significant operational cost : Availability, the indefinite blocking problem.
When a transaction coordinator fails after cohorts have voted YES, those services remain frozen—holding locks, waiting for a decision that may never come. For systems demanding perfect uptime, this blocking behaviour is unacceptable. So, how do the big players— the payment processors, the e-commerce giants—handle a complex distributed transaction like an order placement that spans Inventory, Payment, and Shipping micro services?
Enter the Saga Pattern—a fundamentally different approach that trades strict atomicity for availability and resilience.
Rethinking Distributed Transactions
The Saga Pattern represents an architectural shift in how we think about distributed transactions. Rather than enforcing one massive, all-or-nothing transaction with global locks, we break the workflow into a sequence of smaller, independent local transactions. When a step fails, we don’t attempt to roll back the database state. Instead, we execute a series of compensating transactions to undo the business impact.
With 2PC, transaction services would need to coordinate, hold locks, and wait for a global commit decision.
With Sagas, each service completes its work independently and immediately releases its resources.
Breaking Free from the Lock Chain
The connection to 2PC’s blocking problem is direct. In 2PC, cohorts must acquire and hold locks on resources—like account balances or inventory items—for the entire duration of the global transaction. If the coordinator crashes, those locks never get released, causing system-wide stalls.
Sagas solve this through a simple but powerful mechanism: local transactions with immediate lock release.
Here’s how it works:
- A service performs its required operation (debiting an account, reserving inventory)
- It commits that change to its local database immediately
- It releases all locks right away
Because locks are held only for the brief duration of a local database operation, coordinator failures cannot cause indefinite blocking. The system remains available even when individual steps fail.
The Price of Availability: Eventual Consistency
This approach solves the blocking problem, but it introduces a new characteristic: temporary inconsistency. For a brief period, a debit might be committed and its lock releases before the corresponding credit has even begun. The system exists in an intermediate state that wouldn’t be possible with strict ACID transactions.
This is where compensating transactions become essential. A compensating transaction is an operation designed to undo the effect of a previous local transaction semantically, without requiring the original lock or rolling back committed data.
If a local transaction debits an account with DEBIT_ACCOUNT(A, 100), the compensating transaction reverses it with CREDIT_ACCOUNT(A, 100). Similarly, RESERVE_STOCK(Item, 1) is compensated by UNRESERVE_STOCK(Item, 1).
The key insight – We don’t physically roll back data. Instead, we move forward to a new, correct state through counter-transactions.
A Practical Example: Failed Transfer Without Account Locking
Let’s walk through a transfer from a Savings account to a Trading account that encounters an error:
The money is back in the Savings account, and at no point was the entire system frozen. We traded Strong Consistency for Availability and managed the error with smart, compensating logic.
Two Approaches to Saga Implementation
There are two primary ways to coordinate Saga sequences, each with distinct trade-offs:
- The Event-Driven Flow
- How it Works: There is no central coordinator. Services talk to each other directly via a Message Broker – A queue system (like Pubsub ,Kafka or RabbitMQ ). Service A completes its local transaction and emits an event (e.g., PaymentProcessed). Service B listens to that event and starts its own local transaction.
- Advantage: Extreme Decoupling with no single point of failure (SPOF) for orchestration.
- Disadvantage: Complexity in Tracking. The end-to-end flow is implicit, making monitoring, debugging, and understanding the compensation paths complicated.
- Orchestration (The Central Conductor)
- How it Works: A dedicated service, the Saga Orchestrator, manages the entire workflow. It sends direct commands to the participant services and receives status updates back.
- Advantage: Clear Flow and Debugging. All business logic for the transaction sequence is centralised.
- Disadvantage: SPOF(Single Point Of Failure) Risk. The Orchestrator itself is a potential single point of failure. It must be built to be extremely highly available (HA) and durable.
The Final Trade-Off: Eventual Consistency
While Sagas solve the critical availability and blocking problems of 2PC, they introduce a required state known as Eventual Consistency. For the transient period between the local debit commit and the compensation event, the system state is temporarily inconsistent. A user checking their balance might see the debit, but the credit hasn’t appeared yet.
For most modern systems—especially high-volume FinTech—this brief window of eventual consistency is a totally acceptable engineering trade-off for massive gains in performance, resilience, and horizontal scalability.
The choice between 2PC and Sagas isn’t about right or wrong. It’s about understanding the trade-offs and choosing the right tool for your specific requirements.
While this hybrid approach successfully balances availability and atomic integrity, the complete architectural vision requires one final synthesis. In our following and concluding post, “The way we do here at iServeU: Synthesizing Atomicity and Resilience for the Core Wallet Stack,” we’ll reveal how these patterns unite into a unified operational framework.
In our concluding post, “The way we do here at iServeU: Synthesizing Atomicity and Resilience for the Core Wallet Stack,” we’ll reveal how these seemingly opposing patterns can be unified into a hybrid architecture that refuses to compromise on either integrity or availability.
Author
Sovit Acharya, Principle Engineer
Working at the intersection of technology and finance, building robust systems that enable seamless digital transactions. He is passionate about designing and scaling cloud-native architectures for fintech ecosystems, with expertise in GoLang, Kubernetes, and high-performance distributed systems.
