Two-phase commit and the Saga pattern provide similar solutions in a certain sense. Two-phase commit by Atomikos provides additional benefits compared to Sagas, and so does TCC. See the table below for details as to how Atomikos compares to Sagas, as well as what TCC can do…

Why trust us?

Unlike most people out there, we have implemented both compensation-based systems like Sagas, and XA / two-phase commit. Below is our comparison table for you to make an easy and safe decision. We're comparing Saga solutions against the Atomikos embodiment of XA / two-phase commit (optimised for microservices and cloud: no single point of failure and with support for elastic scaling) and our improved Saga-like TCC (Transactions for SOA) pattern that has been gaining traction around the world.

Comparison table

Feature	Benefit	Atomikos XA / 2-phase commit	Atomikos TCC	Saga pattern	Remarks
XA drivers available?	Automatic rollback support by DBMS or broker				You have to implement the rollback logic yourself, it's more expensive and (in case of Sagas) allows dirty reads.
Heterogeneous systems supported	Can we integrate .Net and Java, and polyglot persistence?				TCC and Saga support any backend or service that complies to the API contract. For TCC there is a published API contract, for Sagas the situation is less clear. Atomikos XA only supports Java systems and (primarily) XA backends.
Avoidance of dirty reads	Correct reporting and read operations				Sagas can be compensated later, but intermediate reads are allowed. This is like dirty reads in the database at the SQL level and usually a big turn-off for most systems.
Automatic handling of undo failure	Increased simplicity and reliability at an even lower cost				Non-XA solutions require custom coding without a clear API description and suffer from idempotent consumer pitfalls.
NO "single point of failure" (SPOF)	Can we avoid a critical bottleneck node?				Nodes can be clustered for resilience.
Pre-tested transaction logic	Increased reliability at a lower cost				Is the transaction logic tested by a vendor implementation?
Automatic "rollback" after timeout / HTTP errors	Increased reliability at a much lower cost				If HTTP requests time out, there is uncertainty at the calling end about whether the remote committed any changes, or none at all. This can lead to either orphaned, duplicate or lost updates.
Commercial support available	Fast solution for problems				Can you get fast expert assistance if things break?

What our customers are saying

We implemented XA / two-phase commit for microservices - not because we wanted to, but because our customers did not like the cost of developing compensation logic for their APIs: it is too much overhead and too hard to test (at least for microservice components within one company). After the WS-* failure we did not believe in any kind of transaction remoting mechanism any more, but changed our minds due to popular demand in our community. Now we have something simpler that just works, without extra coding or testing overhead.

Our take

Sagas were invented for centralised DBMS solutions 30 years ago. They were never really designed for microservices and distribution because they can't cope well with communication failures / timeouts: while they may increase "availability", they do so by allowing dirty reads in between a service invocation and its compensation / undo. So you are never really sure of whether your reads are correct or not, the value you read may still be compensated for later.

So what do you do? It's simple:

• Use XA / Atomikos for microservice components within one controlling department / ownership, and get automatic transaction reliability as a result with no extra coding or testing efforts.
• Use TCC for transactions across owning departments so you get the advantages of Sagas without the drawbacks.
• Avoid Saga solutions unless you are doing what they were designed for: a monolith without distributed interactions.

So why does everybody talk about Sagas?

In one word: marketing. The western world has been hearing about Sagas because "two phase commit is unavailable for microservices". That's understandable, because the gurus and platform vendors who were spreading this message simply lacked access to the right technology. Not any more (we offer it). By the way, TCC is really popular in China, where they have different channels and less influence from the West.

Want to try XA (for FREE)?

Download our free / open source product and see how you can solve your microservice transaction problems with Atomikos. Click the button below to get it directly in your inbox!

Download Now I have read and accept the privacy policy.

Our privacy policy is brief and clear: we do not sell the information you give us. Plus, we'll send you relevant content (only). Our hosting platform is technically dependent on cookies so we can't realistically offer you a no-cookie experience. By continuing your visit, you are assumed to agree with this fact.