Distributed Transactions: Concepts, TCC and Saga Patterns, and Practical Implementation

1. Background

With the rise of micro‑service architecture, many companies are decomposing their business systems into independent services. This leads to data isolation per service and creates serious data‑consistency challenges. Distributed transactions are introduced as a solution to these problems.

2. Transaction Basics

A transaction is the smallest unit of work in a database, executed as a single logical operation. It must satisfy the ACID properties:

Atomicity (A): all operations succeed or none do.

Consistency (C): database constraints remain intact before and after execution.

Isolation (I): concurrent transactions do not interfere with each other.

Durability (D): once committed, changes persist permanently.

3. Distributed Transactions

In a distributed system, a transaction may involve multiple services that need to cooperate over the network. Two main categories exist:

Single‑service transactions that touch multiple database tables.

Multi‑service transactions where each service may have its own database.

Two consistency models are commonly used: strong consistency (e.g., 2PC/3PC) and eventual consistency. Strong consistency is often unsuitable for micro‑services due to cross‑service data access limitations, heterogeneous data stores, and long‑running global transactions that cause locking and performance issues. Therefore, eventual consistency is usually preferred.

4. Business Scenario

A points‑based sign‑in system requires the following steps:

User signs in and gains points.

An order for redeeming a product is created and marked as paid.

User points are deducted.

Product inventory is decreased.

A logistics outbound order is generated.

To guarantee data consistency across these steps, a distributed transaction solution is needed.

4.1 TCC Pattern

The Try‑Confirm‑Cancel (TCC) pattern splits each business operation into three phases:

Try – prepare the business (e.g., reserve resources).

Confirm – commit the business if all Try phases succeed.

Cancel – roll back all prepared actions if any Try fails.

Applying TCC to the scenario would require each service to implement Try, Confirm, and Cancel APIs, which introduces significant intrusion and operational cost.

4.2 Saga Pattern

Saga is a compensation‑based approach where each local transaction has a corresponding compensating transaction. Execution proceeds sequentially (T1 → T2 → … → Tn). If a failure occurs, the previously completed steps are compensated in reverse order (Cn → … → C1). Two recovery strategies exist:

Backward recovery – execute compensating actions for all completed steps.

Forward recovery – retry the failed step until it succeeds.

Advantages of Saga include a simpler model and lower implementation overhead (only transaction and compensation interfaces are needed). Drawbacks involve potential side effects because the original transaction logic runs even if a later step fails.

5. Summary

No single distributed‑transaction solution fits all scenarios. 2PC/3PC provide strong consistency but suffer from blocking and are limited to database‑level transactions. Saga and TCC offer compensating‑transaction models with higher business intrusion. Event‑driven or “maximum‑effort‑notification” approaches achieve eventual consistency and are suitable for time‑tolerant use cases.