I'm developing my insight about distributed systems, and how to maintain data consistency across such systems, where business transactions covers multiple services, bounded contexts and network boundaries.
Here are two approaches which I know are used to implement distributed transactions:
2PC is a protocol for applications to transparently utilize global ACID transactions by the support of the platform. Being embedded in the platform, it is transparent to the business logic and the application code as far as I know.
Sagas, on the other hand, are series of local transactions, where each local transaction mutates and persist the entities along with some flag indicating the phase of the global transaction and commits the change. In the other words, state of the transaction is part of the domain model. Rollback is the matter of committing a series of "inverted" transactions. Events emitted by the services triggers these local transactions in either case.
Now, when and why would one use sagas over 2PC and vice versa? What are the use cases and pros/cons of both? Especially, the brittleness of sagas makes me nervous, as the inverted distributed transaction could fail as well.
Typically, 2PC is for immediate transactions. Typically, Sagas are for long running transactions.
Two-phase commit (2PC) is a standardized protocol that ensures atomicity, consistency, isolation and durability (ACID) of a transaction; it is an atomic commitment protocol for distributed systems.
The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step.
The coordinator implements the commit handling in two phases. It first sends the prepare request to each of the participants. Once it receives a successful response from all the participants, the coordinator marks the transaction as prepared to complete. Then it sends the commit request to all the participants.
In my understanding (not a big user of 2PC since I consider it limiting):
Use cases are obvious afterwards:
Example:
I personally consider Saga capable of doing what 2PC can do. Opposite is not accurate.
I think Sagas are universal, while 2PC involves platform/vendor lockdown.
Updates/Additions (optional read):
My answer has been here for a while, and I see that the topic has gained some traction since.
I want to clarify a couple of points on this topic for those who come here and are not sure which route to take.
@freakish in the comments mentioned a fair point: 2PC prefers consistency, while Saga degrades it to "eventual consistency." If you have a situation where consistency is more important than availability (please read CAP), then maybe you do need a system transaction protocol like 2PC. Otherwise, I recommend going with business transactions such as Saga. Please read System Transactions vs Business Transactions e.g. in PEAA.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With