2PC vs Sagas (distributed transactions)

Question

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:

• 2-phase commit (2PC)
• Sagas

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.

Answer 1

In my understanding (not a big user of 2PC since I consider it limiting):

• Typically, 2PC is for immediate transactions.
• Typically, Sagas are for long running transactions.

Use cases are obvious afterwards:

• 2PC can allow you to commit the whole transaction in a request or so, spanning this request across systems and networks. Assuming each participating system and network follows the protocol, you can commit or rollback the entire transaction seamlessly.
• Saga allows you split transaction into multiple steps, spanning long periods of times (not necessarily systems and networks).

Example:

• 2PC: Save Customer for every received Invoice request, while both are managed by 2 different systems.
• Sagas: Book a flight itinerary consisting of several connecting flights, while each individual flight is operated by different airlines.

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.

Answer 2

Your comparisons are not logically consistent. Older solutions like Sagas take more work to implement that XA/2PC

Typically, 2PC is for immediate transactions. Typically, Sagas are for long running transactions.

this is incorrect, XA transactions can run for weeks if you want, no-timeouts are an option. I've worked with systems where XA/2PC run for a week, some where they run for 1ms.

I personally consider Saga capable of doing what 2PC can do. Opposite is not accurate.

No, Sagas are a more primitive solution to XA. XA is the newer solution. In Sagas boilerplate needs to be developed to handle the transactions. XA moves the common elements of transaction management to the underlying platform, reducing the boiler plate bloat developers have to manage.

I think Sagas are universal, while 2PC involves platform/vendor lockdown.

XA spec has been implemented by many vendors and is pretty universal. Implementing 2PC across multiple platforms across multiple organizations has not been a problem for over 30 years.