Distributed Transaction Solutions: 2PC, TCC, and Message Queue Eventual Consistency

Distributed Systems and Transactions

A distributed system consists of multiple nodes interacting over a network to complete a task. For example, a recharge-and-points business requires a recharge system and a points system to collaborate.

A transaction is a unit of work with ACID properties: atomicity (all operations succeed or all roll back), consistency (data moves from one valid state to another), isolation (concurrent transactions do not interfere), and durability (committed changes survive failures).

A local transaction uses a single relational database to enforce ACID. A distributed transaction spans multiple systems or multiple data sources, requiring coordination across the network.

CAP Theorem

CAP states a distributed system can only guarantee two of three properties: Consistency (all nodes see the same data at the same time), Availability (every request receives a response), and Partition Tolerance (the system continues operating despite network partitions).

CA : Relational databases; sacrifice partition tolerance.

AP : Many NoSQL databases; sacrifice strong consistency for availability and partition tolerance, achieving eventual consistency.

CP : Systems requiring strong consistency (e.g., cross-bank transfers); sacrifice availability during partitions.

In practice, AP is common: guarantee partition tolerance and availability, accept eventual consistency (e.g., refund processed today, funds arrive tomorrow).

Two-Phase Commit (2PC)

Prepare Phase

Coordinator asks all participants to vote.

Each participant executes local transaction, writes redo/undo logs, but does not commit. Participants reply "agree" (success) or "abort" (failure).

Commit Phase

If all vote "agree": coordinator sends commit; participants commit, release locks, reply "done"; coordinator finishes.

If any votes "abort" or timeout: coordinator sends rollback; participants undo using logs, release locks, reply "rolled back"; coordinator cancels.

Drawbacks

Synchronous blocking: participants hold locks during the process.

Single point of failure: coordinator crash leaves participants blocked.

Data inconsistency: network failure during commit can leave some participants committed, others not.

Unresolvable scenario: coordinator crashes after sending commit, and the only participant that received it also crashes; transaction state becomes unknown.

Try-Confirm-Cancel (TCC)

TCC implements distributed transactions at the business layer with three operations:

Try : Check and reserve resources (e.g., order service checks order conditions; inventory service checks and locks stock).

Confirm : Execute the actual business logic (order service writes order; inventory service deducts stock).

Cancel : Release reserved resources if any step fails (order service deletes order; inventory service restores stock).

Pros: ensures eventual consistency, flexible business-layer control. Cons: high development cost — each participant must implement three interfaces. All interfaces must be idempotent to support retries.

Idempotency

An idempotent operation yields the same result regardless of how many times it is executed. Implementation approaches:

Check business state before execution; skip if already processed.

Cache request and result; return cached result for duplicate requests.

Add a status column (e.g., unprocessed/processed) in the database; process only when unprocessed.

Message Queue for Eventual Consistency

This approach splits a distributed transaction into multiple local transactions coordinated asynchronously via a message queue (e.g., RabbitMQ). Example: order placement with inventory deduction.

Order and inventory services check and reserve resources.

Order service writes order record and a "reduce inventory task" message in a local transaction.

A scheduled job reads the message table and publishes to MQ.

Inventory service consumes message, deducts stock, records execution status (checks for duplicate processing).

Inventory service sends completion message to MQ.

Order service receives completion and deletes the task message.

Pros: higher performance due to async coordination; lower development cost than TCC. Cons: relies on relational database for message storage, causing frequent reads/writes; not ideal for high concurrency.

Conclusion

The article introduces distributed transaction fundamentals, CAP trade-offs, and three solution patterns. A follow-up article will detail the message queue eventual consistency implementation using RabbitMQ, Spring Task, and Spring Cloud.