Choosing Between Seata‑AT, TCC, and Saga for Distributed Transactions

In monolithic applications a simple @Transactional annotation can guarantee atomicity, but in a micro‑service architecture each service has its own database, leading to scenarios where, for example, a points deduction succeeds while the order insert fails. The article examines three popular distributed‑transaction solutions—Seata‑AT, TCC, and Saga—and shows how to select the appropriate one.

1. Seata‑AT

Seata‑AT is the automatic transaction mode of the Seata framework. By adding @GlobalTransactional, developers obtain cross‑service consistency without code intrusion. It implements an improved two‑phase‑commit (2PC) protocol:

Phase 1 (Prepare) : Business SQL is intercepted, a snapshot of the data before the change is stored, the SQL is executed, and a snapshot after the change is saved. An undo_log is generated, then the local database transaction is committed and resources are released.

Phase 2 (Commit/Rollback) : On commit, Seata asynchronously clears the snapshots and row locks; on rollback, it uses the undo_log to generate reverse SQL and restore data.

Because the local DB lock is released after Phase 1, other transactions that are not annotated with Seata can read uncommitted data, causing dirty reads and dirty writes. The article shows a diagram of this problem and explains that Seata mitigates it by acquiring a global lock before releasing the DB lock. However, under high concurrency the global lock becomes a bottleneck, degrading performance, as illustrated by another diagram.

Advantages :

Phase 1 commits and releases DB resources quickly, yielding good performance.

Global lock provides read‑write isolation.

No code changes required; the framework handles commit and rollback automatically.

Disadvantages :

The soft state between the two phases leads to eventual consistency; the snapshot mechanism can impact performance.

2. Seata‑TCC

TCC (Try‑Confirm‑Cancel) is suited for core e‑commerce transactions because it does not rely on database transactions but on business‑level 2PC. The process is split into three stages, each represented by a separate interface method, and the business tables must be extended (e.g., adding a frozen column to a points table) to reserve resources.

The article highlights three practical concerns when implementing TCC:

Empty Rollback : If the Try request is lost (e.g., packet loss) and the Transaction Manager (TM) sends a Cancel, the Cancel should be ignored when no Try record exists. The solution is a transaction‑control log table that records Try attempts; Cancel checks this table before acting.

Hanging (悬挂) : Network congestion may cause Cancel to arrive before Try. If Try later executes without checking, resources could be frozen unnecessarily. The solution again uses the log table: Try checks for an existing Cancel record and aborts if found.

Idempotency : Network jitter can cause Confirm and Cancel to be retried multiple times. The article recommends using the global transaction ID as a unique index to ensure each phase is processed only once.

3. Saga

Saga is appropriate when a service interacts with third‑party systems (e.g., bank APIs) that cannot participate in a distributed transaction, making TCC infeasible. Saga follows a “no‑reservation” approach: the forward operation directly calls the third‑party service, and if a failure occurs, a compensating action (e.g., refund) is executed.

Key points for Saga:

Both the forward and compensating actions must be idempotent because network timeouts can cause retries.

Conclusion and Recommendation

The article summarizes the suitable scenarios for each pattern:

Seata‑AT : Non‑intrusive, best for back‑office management systems and non‑core business where eventual consistency and moderate performance are acceptable.

TCC : Provides strong consistency and high concurrency, but requires code intrusion and table modifications; ideal for core transactional services that do not involve third‑party systems.

Saga : Also offers eventual consistency with high concurrency, does not require table changes, and is suited for workflows that involve third‑party APIs or legacy systems.

By weighing factors such as code invasiveness, need for strict consistency, performance under high load, and integration with external services, developers can choose the most appropriate distributed‑transaction solution for their micro‑service project.