Distributed Transaction Solutions: 2PC, 3PC, XA, TCC, Saga, Local Message Table, Transactional Messages, and Seata

In the era of micro‑service architecture, ensuring business consistency across distributed services is critical, making distributed transactions essential.

It begins by recalling the ACID properties of single‑node database transactions and notes that distributed transactions must also satisfy these four guarantees.

The article then outlines the challenges introduced by network communication, which adds a third possible outcome (unknown) and various failure scenarios such as node crashes, message loss, and ordering issues.

Distributed Transaction Solutions

2PC/3PC : Two‑phase commit (2PC) uses a coordinator and participants to ensure all nodes either commit or roll back, but suffers from synchronous blocking, coordinator single‑point failure, and potential data inconsistency. Three‑phase commit (3PC) adds an extra phase and timeout handling but does not fundamentally solve 2PC’s problems.

XA : An extension of 2PC that defines how resources (e.g., MySQL, Oracle) participate in the commit protocol.

Local Message Table : A widely used approach where business operations and message writes are placed in the same local transaction, with a scheduled task polling the table to send messages, ensuring eventual consistency while keeping implementation simple.

Transactional Messages : Leveraging message middleware (e.g., RocketMQ) to decouple business data from message tables; the producer sends a half‑message, performs local work, then confirms the message, with the broker handling retries and rollbacks.

TCC (Try‑Confirm‑Cancel) : An application‑level two‑phase protocol where each operation implements Try, Confirm, and Cancel methods; it offers strong consistency but requires extensive business‑level code and careful handling of failures.

Saga : Breaks a long‑running transaction into a series of local transactions coordinated by a workflow engine; compensating actions are executed in reverse order on failure, providing higher performance at the cost of weaker consistency.

Seata : An Alibaba‑backed open‑source framework offering AT, TCC, Saga, and XA modes. AT intercepts SQL to create before/after images and row locks, providing non‑intrusive transaction management; Seata also supports TCC and Saga with similar principles.

Consistency vs. Consensus : The article compares distributed transaction consistency (atomicity) with Paxos‑based consensus, noting that while both aim for agreement, they operate at different layers; Paxos can help address coordinator single‑point failures in 2PC.

Conclusion : Achieving both high consistency and high performance in distributed transactions is difficult; the recommended practical hierarchy is business avoidance > eventual consistency > strong consistency.