Mastering Distributed Transactions: Protocols, Patterns, and Seata Explained

Distributed Transactions

In the era of micro‑service architectures, ensuring business consistency across multiple distributed services—i.e., handling distributed transactions—is crucial. This article introduces distributed transactions and their solutions, including the XA protocol, TCC and Saga models, local message tables, transaction messages, and Alibaba’s open‑source Seata.

Fundamentals of Transactions

Before discussing distributed transactions, recall the ACID properties of a single‑node (database) transaction:

Atomicity – all operations succeed or all fail.

Consistency – data integrity is preserved before and after the transaction.

Isolation – rules governing data visibility among concurrent transactions.

Durability – once committed, data is permanently stored.

Distributed transactions must also satisfy these four properties, but network communication introduces uncertainty, turning the simple success/failure outcome into success, failure, or unknown.

Distributed Transaction Solutions

2PC/3PC

Two‑Phase Commit (2PC) is a protocol that ensures all nodes either commit or roll back a transaction, mirroring the atomicity aspect of ACID. A coordinator orchestrates the process:

Prepare phase – the coordinator sends a Prepare message; participants perform a pre‑commit and reply with success or failure.

Commit phase – if all participants succeeded, the coordinator sends Commit; otherwise it sends Rollback.

While 2PC provides strong consistency, it suffers from synchronous blocking, a single‑point‑of‑failure coordinator, and potential data inconsistency if some participants miss the commit.

3PC

Three‑Phase Commit (3PC) adds an extra phase (splitting the prepare into CanCommit and PreCommit) and introduces timeouts to mitigate 2PC’s blocking issue, but it does not fundamentally solve the underlying problems.

XA

XA is a standard built on 2PC that defines how relational databases implement the protocol; common XA‑compatible databases include MySQL and Oracle.

Local Message Table

The local message table pattern, originally proposed by eBay, treats a distributed transaction as a local one by writing a message to a table within the same transaction as the business operation. A scheduled task later polls the table and sends pending messages to a message broker. The workflow:

The initiator writes business data and a message record in a single local transaction.

A background job reads unsent messages and publishes them to the broker.

The consumer processes the message and acknowledges success.

The initiator updates the message status to “sent”.

This approach relies on the broker’s reliability to achieve eventual consistency.

Transaction Message

Transaction messages, supported by RocketMQ, decouple the local message table from business data. The steps are:

The producer sends a “half” message (status = prepare) to RocketMQ; the consumer cannot consume it yet.

The producer executes the local transaction.

The producer confirms the message, turning it into a consumable message.

If steps 1 or 3 fail, RocketMQ periodically scans unconfirmed messages and asks the producer for the transaction status, then either commits or rolls back the message.

TCC (Try‑Confirm‑Cancel)

TCC is a compensation‑based model where each operation registers a try, confirm, and cancel action. It works like an application‑level 2PC without a resource manager:

Try – validate and reserve resources.

Confirm – commit the reserved resources.

Cancel – release the reserved resources.

Failure handling relies on business logic, and popular implementations include ByteTCC and tcc‑transaction.

Saga

Saga splits a long‑running transaction into a series of short local transactions coordinated by a workflow engine. If any step fails, the engine triggers compensating actions in reverse order. Compared to TCC, Saga has weaker consistency but higher performance and simpler integration.

Seata

Seata, an Alibaba‑backed framework, offers four transaction modes: AT, TCC, Saga, and XA.

AT Mode

AT intercepts business SQL, creates before/after images, and locks rows in the first phase. The second phase simply deletes the snapshots and releases locks, achieving atomicity without invasive code changes.

Seata TCC Mode

Seata’s TCC implementation follows the standard TCC model described earlier.

Seata Saga Mode

Seata adds a state‑machine engine to orchestrate Saga workflows, providing a standardized yet more complex configuration.

Consistency vs. Paxos

All the solutions above (TCC, Saga, local message table, etc.) fundamentally rely on 2PC‑style coordination. Paxos, on the other hand, solves consensus—agreeing on a value among replicas—not atomic transaction commit. Paxos can address coordinator single‑point failures by electing a new leader.

Conclusion

Distributed transaction solutions rarely achieve both strong consistency and high performance simultaneously, and they often involve considerable implementation complexity. In practice, the guiding principle is to prioritize business avoidance, then eventual consistency, and finally strong consistency when the domain permits.