Mastering Distributed Transactions: 5 Solutions, Patterns, and Their Trade‑offs

Overview

A transaction is a set of operations that must either all succeed or all be rolled back. The classic example is a bank transfer, which requires atomicity, consistency, isolation, and durability (ACID).

Distributed Transaction Scenarios

Cross‑database distributed transaction

Cross‑service distributed transaction

Hybrid distributed transaction

Distributed Transaction Patterns

XA Specification (Two‑Phase Commit)

The XA specification defines four core roles: Resource Manager (RM), Transaction Manager (TM), Application Program (AP), and Communication Resource Manager (CRM). It uses a prepare phase and a commit/rollback phase, logging each step. Optimizations include one‑phase commit when only one RM is involved, read‑only shortcuts, and heuristic completion. However, the protocol holds locks for the entire transaction, leading to long blocking times and poor suitability for micro‑service architectures.

TCC (Try‑Confirm‑Cancel)

TCC is a compensating transaction model that requires each service to implement three interfaces: try, confirm, and cancel. It reserves resources in the try phase, commits them in confirm, or releases them in cancel. An e‑commerce order example illustrates how each subsystem (order, payment, inventory, loyalty) follows these steps. TCC avoids long‑lasting locks but incurs higher business‑level intrusion.

Saga

Saga treats a distributed transaction as a chain of local transactions, each with a compensating action. If any step fails, the saga executes compensations in reverse order. The pattern provides atomicity and eventual consistency but does not guarantee isolation, which can cause complications when compensations depend on intermediate state.

Message‑Based Distributed Transactions

Two approaches exist: transactional messages and local messages. Transactional messages are persisted in the MQ system in a *prepared* state until the local transaction outcome is known, then become consumable. Local messages store a “to‑send” record in a database table and a background task retries sending until success. Both decouple participants but require reliable MQ support.

Maximum‑Effort Notification

This pattern achieves eventual consistency by sending a best‑effort notification (e.g., via MQ) and periodically retrying or pulling the transaction status if the notification fails. It has low business intrusion and modest MQ requirements, suitable for short‑lived, low‑consistency‑sensitivity scenarios.

Middleware

Alibaba offers two distributed‑transaction middleware products—XTS/DTX and TXC—both open‑sourced as Seata . Seata supports AT (Automatic Transaction) mode, which automatically records before/after images of SQL statements to generate rollback logs, as well as TCC and Saga modes. AT works only with ACID‑compliant relational databases and has limitations such as no support for composite primary keys.

Summary

Strong‑consistency (rigid) transactions like XA guarantee full ACID properties but sacrifice availability. Flexible transactions—TCC, Saga, message‑based, and maximum‑effort notification—provide eventual consistency (BASE), higher availability, and better scalability, at the cost of weaker isolation. Choose the solution that matches the consistency requirements of your business scenario.