Saga Pattern vs Two Phase Commit vs TCC
Comparison: should you use the saga pattern, TCC or 2-phase commit?

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

FeatureSorted ascending Benefit Atomikos XA / 2-phase commit Atomikos TCC Saga pattern Remarks
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.
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.
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.
Commercial support available Fast solution for problems Can you get fast expert assistance if things break?
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.
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?
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.

= included = under construction = not included

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)?

Apply for our free trial and see how you can solve your microservice transaction problems with Atomikos. We'll even help and support you - who else will do that? Click the button below to get in touch!

Free Trial

Contact Us

Atomikos Corporate Headquarters
Hoveniersstraat, 39/1, 2800
Mechelen, Belgium

E info@atomikos.com
E sales@atomikos.com
T +3215613055

Subscribe to our newsletter

Never miss an update

Copyright 2020 Atomikos BVBA
This website is using cookies. More info. That's Fine