Mastering Distributed Transactions: From Local Basics to Advanced Solutions

ACID

Transactions guarantee that a group of operations executes as an indivisible unit, following the 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 operate on independent data snapshots, never seeing intermediate states.

Durability : Once committed, changes survive system crashes.

Monolithic Transactions

In a monolithic architecture a single database handles all business logic, so native DB transaction mechanisms (locks, undo/redo logs) are sufficient. For example, MySQL uses lock‑based isolation, undo logs for consistency, and redo logs for durability.

Distributed Transactions

When services are split into multiple databases (vertical or horizontal sharding) a single operation may span several databases. Native DB transactions only protect the local database, so a distributed transaction protocol is required to preserve the "all‑or‑nothing" guarantee across all involved resources.

XA / 2PC Two‑Phase Commit

XA

XA is a distributed‑transaction protocol defined by Tuxedo. It involves three roles:

AP (Application) : the client service.

TM (Transaction Manager) : coordinates the global transaction.

RM (Resource Manager) : the participating database.

XA uses a two‑phase commit (2PC) to ensure all participants either commit or roll back.

2PC Process

The protocol consists of a prepare phase and a commit phase:

Prepare phase : the coordinator asks all participants if they can commit.

Commit phase : if every participant replies "yes", the coordinator issues a commit; otherwise it issues a rollback.

Drawbacks include a single point of failure at the coordinator and synchronous blocking, which can degrade performance.

3PC Three‑Phase Commit

3PC extends 2PC by adding timeout mechanisms to both the coordinator and participants, eliminating the single‑point‑failure problem and reducing blocking.

The three phases are: CanCommit: participants indicate readiness. PreCommit: coordinator ensures all are ready before proceeding. DoCommit: final commit or abort based on acknowledgments.

TCC (Try‑Confirm‑Cancel)

TCC is a variant of 2PC where each business operation has explicit Try, Confirm, and Cancel methods. It provides compensation at the business level rather than the database level.

Try : validate and reserve resources.

Confirm : finalize the operation; assumed to succeed if Try succeeded.

Cancel : release reserved resources on failure.

Example: order creation reserves inventory in the Try step; Confirm marks the order as paid and deducts inventory; Cancel releases the reservation.

Local Message Table

This pattern splits a distributed transaction into a local transaction plus an asynchronous message. The order service writes both the order and a message into the same DB transaction, then a scheduler polls the message table and pushes messages to a message queue for downstream services.

MQ Transaction

MQ‑based transactions use a "prepare‑then‑commit" pattern: a prepare message is sent to the broker, the local transaction runs, and on success the broker commits the message; on failure the broker discards the prepare message.

Maximum‑Effort Notification

This simple approach is suitable for low‑consistency scenarios (e.g., payment or SMS notifications). The system retries up to a configurable limit; after that it stops and relies on a manual query interface.

Saga

Saga breaks a long transaction into a series of short local transactions coordinated by a saga orchestrator. If any step fails, compensating actions are executed in reverse order.

Normal flow: T1 → T2 → … → Tn Compensation flow:

T1 → T2 → … → Ti → Ci → … → C1

Seata

Seata is an open‑source distributed‑transaction framework from Alibaba. It supports multiple modes: AT (automatic transaction), TCC, Saga, and XA. Integration is lightweight—adding @GlobalTransactional to a method enables a global transaction.

Key components:

TC (Transaction Coordinator) : manages global transaction state.

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

RM (Resource Manager) : registers branch transactions with the TC.

Typical workflow:

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

Service A’s RM registers a branch transaction under that XID.

Service A executes its branch transaction and calls Service B.

Service B’s RM also registers a branch transaction under the same XID.

Both services complete their local work.

TM decides to commit or roll back based on success, and TC coordinates the final decision across all RMs.

Conclusion

The article covered eight distributed‑transaction solutions—2PC, 3PC, TCC, local message tables, maximum‑effort notifications, MQ transactions, Saga, and Seata—highlighting their trade‑offs and practical pitfalls. Choosing a solution requires careful assessment of consistency requirements, performance impact, and operational complexity.