How to Choose the Right Distributed Transaction Pattern for Microservices

Typical Distributed Transaction Scenarios

Service‑to‑service call retries that must guarantee delivery, e.g., sending a notification after an order is placed.

Cross‑domain consistency such as asynchronous points or membership‑level updates after a purchase.

Account‑balance adjustments where a debit must be rolled back if the order is cancelled, requiring coordination between separate services.

Inventory consistency, the most contentious case in supply‑chain systems because inventory is a high‑contention resource.

These scenarios fall into two groups: (1) non‑contentious cases that can be solved with simple retries, and (2) contentious cases that need to be transformed into a non‑contentious form.

Theoretical Foundations

The CAP theorem states that a distributed system can provide at most two of the three guarantees: Consistency, Availability, and Partition tolerance.

Consistency : all partitions see the same state.

Availability : operations proceed without waiting for consensus.

Partition tolerance : the system continues to operate despite network partitions.

In microservice architectures only CP or AP configurations are realistic. If the window for achieving consistency is short enough (e.g., a nightly batch), the “simultaneous” requirement can be relaxed, enabling eventual consistency within acceptable business latency.

For non‑contentious cases eventual consistency works well. For contentious cases the core idea is to temporarily occupy the contested resource, execute the long‑running business logic asynchronously, and release the resource later. This is the essence of the Try‑Confirm‑Cancel (TCC) pattern.

Industry Concepts and Solutions

ACID vs. BASE

ACID (Atomicity, Consistency, Isolation, Durability) is the foundation of relational DBMS transactions. BASE (Basically Available, Soft state, Eventually consistent) is the counterpart for distributed systems, where consistency is achieved at the business layer rather than the database layer.

TCC (Try‑Confirm‑Cancel)

TCC splits a distributed transaction into three explicit phases:

Try : synchronously lock or reserve the required resource; failure aborts the whole transaction.

Confirm : consume the reserved resource, usually performed asynchronously.

Cancel : roll back the reservation if any later step fails.

Implementations typically generate a globally unique transaction ID in the Try phase. The ID is used as an idempotency key for Confirm and Cancel, ensuring that retries do not produce duplicate effects.

JTA / XA

JTA (Java Transaction API) together with the XA protocol enables database‑level distributed transactions. XA requires a central coordinator and database support (e.g., InnoDB in MySQL). The coordinator drives a two‑phase commit across all participants, which introduces heavy centralized locking and is rarely used in modern microservice projects.

Two‑Phase Commit (2PC) and Three‑Phase Commit (3PC)

Both algorithms are coordination mechanisms used by XA. They assume a single coordinator node, reliable pre‑write logs, and persistent participant state.

2PC: prepare phase where each participant records a tentative commit, followed by a commit phase after the coordinator receives unanimous agreement.

3PC adds a prepare‑to‑commit phase that allows participants to detect coordinator failure before the final commit, thus avoiding the blocking problem of 2PC.

Imagine a decision‑making group where a host calls each member to vote. If the host forgets the decision after the first call, the group may end up inconsistent. Adding a preparation step (the third phase) lets the group recover the decision even if the host forgets.

Saga

Saga follows a try‑confirm‑cancel philosophy but does not lock resources. It assumes every participant can cancel its work and that each participant maintains a local transaction. On failure, previously committed steps are compensated (rolled back) by invoking explicit compensation actions.

Saga is suitable when there is no resource contention; otherwise it is rarely used because compensation cannot guarantee the same invariants that a lock would provide.

AT Mode (Automatic Transaction)

AT is Seata’s improvement over XA. It works at the transaction coordinator level, parses SQL statements to lock rows, and sacrifices non‑intrusiveness for performance. AT assumes most branch transactions succeed and commits them without waiting for the coordinator, which can leave the system in a temporarily dirty state under high contention.

Choosing a Distributed Transaction Solution

When selecting a pattern, consider the following decision points:

Is consistency required only at the database layer, or also at the business‑logic layer (e.g., guaranteed notification delivery)?

How invasive is the solution to existing code (e.g., TCC requires explicit Try/Confirm/Cancel methods)?

Is additional coordination infrastructure acceptable (e.g., a XA coordinator or Seata server)?

Does a single transaction involve more than two contested resources?

For contentious scenarios TCC is often preferred because it makes resource contention explicit and provides clear compensation paths. XA can be used when a centralized database transaction is acceptable, but it brings heavy locking and operational overhead. Saga fits non‑contentious, compensatable workflows, while AT offers a performance‑oriented alternative to XA at the cost of temporary inconsistency.

References

An Illustrated Proof of the CAP Theorem – https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/

Brewer’s Conjecture – http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Spring Boot JTA Documentation – https://docs.spring.io/spring-boot/docs/2.0.x/reference/html/boot-features-jta.html

Seata TCC Design Principles – https://seata.io/zh-cn/blog/tcc-mode-design-principle.html

Understanding XA Transactions in Go – https://betterprogramming.pub/understanding-xa-transactions-with-practical-examples-in-go-67e99fd333db

Saga Paper – https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

Seata XA and AT Analysis – https://developer.aliyun.com/article/919377

Code example

相关阅读：