From Local to Distributed Transactions: Choosing 2PC, 3PC, TCC, Saga or Seata

What Is a Transaction?

A transaction groups a set of operations into an indivisible unit that either fully succeeds or fully fails, providing the "all‑or‑nothing" guarantee.

ACID Properties

Atomicity : All operations succeed or none do.

Consistency : The database remains in a valid state before and after the transaction.

Isolation : Concurrent transactions do not interfere; each sees a consistent view.

Durability : Once committed, changes survive system crashes.

Monolithic (Single‑Database) Transactions

In a monolithic architecture, all business logic uses a single database, so the database’s native transaction mechanism (locks, undo/redo logs) is sufficient.

Example with MySQL:

Isolation is enforced by database locks.

Consistency is guaranteed by the undo log, which records insert, update, delete operations and can roll them back.

Atomicity and durability are ensured by the redo log, which must be flushed before a commit is considered complete.

Why Distributed Transactions?

When services evolve into SOA or micro‑services, data is split across multiple databases (vertical or horizontal sharding). A single operation may now span several databases, and each database can only guarantee its own local transaction.

To preserve transaction semantics across databases, a distributed transaction mechanism is required.

Distributed Transaction Solutions

XA / 2‑Phase Commit (2PC)

XA defines three roles: Application (AP), Transaction Manager (TM), and Resource Manager (RM). The protocol follows a prepare phase and a commit phase.

Prepare phase : Coordinator asks participants if they can commit.

Commit phase : If all participants responded positively, the coordinator issues a commit; otherwise it issues a rollback.

Drawbacks: single‑point‑of‑failure at the coordinator, synchronous blocking, and possible inconsistency if some participants miss the commit message.

3‑Phase Commit (3PC)

3PC adds a pre‑commit phase and timeout mechanisms for both the coordinator and participants, reducing the risk of coordinator failure causing indefinite blocking.

Phases: CanCommit → PreCommit → DoCommit. If a timeout occurs in the pre‑commit or commit phase, participants roll back to a safe state.

TCC (Try‑Confirm‑Cancel)

TCC splits each business operation into three methods: Try (resource reservation), Confirm (final commit), and Cancel (compensation). It provides business‑level compensation without holding locks.

Example: order creation reduces inventory in the Try step; if Try succeeds, Confirm finalizes the order and inventory; if Try fails, Cancel releases the reserved stock.

Drawbacks: high code intrusion (three methods per operation) and the need for idempotent APIs and retry logic.

Local Message Table

The idea is to store a message in the same local transaction as the business update, then a scheduled task polls the table and pushes the message to a message queue. Consumers process the queue in their own local transactions.

Pros: achieves eventual consistency with minimal changes to existing services. Cons: extra DB write, latency depends on polling interval, and potential duplicate messages require idempotent handling.

MQ Transaction (Transactional Message)

Uses a message broker’s transactional message feature (e.g., RocketMQ half‑message). The workflow is:

Send a prepare (half) message to the broker.

Execute the local transaction.

If the local transaction succeeds, commit the message; otherwise, rollback and delete the half‑message.

The consumer receives the committed message and processes it in its own transaction.

This approach also provides eventual consistency with less DB overhead than the local‑message‑table pattern.

Max‑Effort Notification

A lightweight pattern for low‑consistency scenarios (e.g., payment notifications). The system retries notification up to a configurable limit; after the limit, it stops and relies on a manual query interface.

Saga

Saga breaks a long transaction into a series of short local transactions, each with a compensating action. A Saga coordinator orchestrates the forward execution; if a step fails, it triggers compensations in reverse order.

Two recovery strategies exist: forward recovery (retry the failed step) and backward recovery (run compensations for already‑completed steps).

Seata

Seata is an open‑source distributed transaction framework from Alibaba. It supports multiple modes: AT (automatic transaction), TCC, Saga, and XA.

Key components:

TC (Transaction Coordinator) : Manages global transaction state and decides commit/rollback.

TM (Transaction Manager) : Starts, commits, or rolls back transactions.

RM (Resource Manager) : Registers branch transactions with the TC and executes commit/rollback commands.

Typical workflow:

TM in Service A requests a global transaction from TC, receiving a unique XID.

RM in Service A registers a branch transaction under that XID.

Service A executes its branch transaction.

Service A calls Service B; the XID propagates via the call chain.

RM in Service B registers its branch transaction.

Service B executes its branch transaction.

After the business logic finishes, TM decides to commit or rollback based on any errors.

TC coordinates all branch transactions to either commit or roll back.

Seata’s AT mode is low‑intrusion (just add @GlobalTransactional), but commercial versions (e.g., GTS) warn about limitations such as long‑running transactions, hot data, and asynchronous calls.

Conclusion

Multiple distributed‑transaction solutions exist—2PC, 3PC, TCC, local message tables, max‑effort notifications, MQ transactions, Saga, and Seata—each with its own trade‑offs. Choosing a solution requires careful assessment of consistency requirements, performance impact, operational complexity, and failure scenarios; avoid distributed transactions unless strong consistency is truly needed.