How Seata’s AT Mode Solves Distributed Transaction Challenges

0. Introduction

From CPU to memory, disk, operating system, and network, computer systems contain many unreliable factors; engineers use protocols such as TCP, RAID5/6, and ARIES‑based transaction mechanisms to ensure correct processing. This article first introduces the ACID properties of single‑database transactions, then points out the difficulties of operating multiple data sources in distributed scenarios, and finally presents common distributed‑transaction solutions that aim to provide ACID guarantees across multiple data sources.

It concludes with an in‑depth look at the industry‑grade distributed‑transaction framework Seata, focusing on its AT mode global‑transaction implementation.

1. Single‑Data‑Source Transaction & Multi‑Data‑Source Transaction

When an application accesses only one database within a business flow, it can rely on the database’s transaction mechanism to guarantee four ACID semantics: Atomicity, Consistency, Isolation, and Durability. For example, MySQL InnoDB implements these semantics using Undo Log + Redo Log + ARIES algorithm.

In distributed scenarios, a system consists of multiple subsystems, each with its own data source. Microservices each maintain an independent database to preserve isolation. For instance, an e‑commerce system may contain shopping, inventory, and order services. A single business operation may involve multiple databases, but local transaction mechanisms cannot ensure global reliability, leading to the need for distributed transactions.

2. Common Distributed‑Transaction Solutions

2.1 Distributed Transaction Model

Key concepts include transaction participants (e.g., each database), transaction coordinator (e.g., the shopping service), Resource Manager (RM) and Transaction Manager (TM). The TM manages multiple RMs, coordinating their local transactions to commit or roll back together, achieving global ACID.

2.2 Two‑General’s Problem and Idempotency

The classic two‑generals problem illustrates uncertainty in network communication. In databases, similar uncertainty arises when a client does not receive a response after sending a write request. Idempotency ensures that repeated requests have the same effect as a single request.

2.3 Two‑Phase Commit (2PC) & Three‑Phase Commit (3PC)

2PC consists of a prepare phase and a commit phase. Participants respond “yes” or “no” in the prepare phase; the coordinator decides to commit or roll back. 2PC suffers from performance bottlenecks, lock holding, and coordinator‑failure issues. 3PC adds an inquiry phase to mitigate blocking but still cannot fully solve crash problems.

2.4 TCC (Try‑Confirm‑Cancel)

TCC is an application‑level 2PC for microservices. The try phase locks resources, confirm commits, and cancel rolls back. Idempotency is required for confirm/cancel operations.

2.5 Transaction‑Status‑Table Scheme

A global transaction table records the status of each step; a background task scans the table and retries unfinished steps until all succeed or marks the transaction as error.

2.6 Message‑Queue Based Final‑Consistency Scheme

This scheme uses a message broker (e.g., RabbitMQ) to achieve eventual consistency. The correct implementation stores a message in a local table and sends it to the broker within a single local transaction, and consumers process messages idempotently, handling ACK loss and network failures.

3. Seata in AT Mode Implementation

3.1 Overview of AT Mode Workflow

Seata’s AT mode builds on relational‑database local transactions, intercepting SQL to record custom undo logs. The two phases are: (1) acquire a local lock, execute the local transaction, record the undo log, and release the lock; (2) if a global commit is required, asynchronously delete the undo logs, otherwise replay the undo logs for compensation.

3.2 Detailed AT Mode Process

Example e‑commerce scenario: the shopping service calls the repo service to deduct inventory and the order service to create an order. The global transaction generates an XID; each branch registers with Seata, commits its local transaction, and reports its status. Seata then decides to commit or roll back globally.

Commit path: Seata sends branch‑commit messages; each branch deletes its undo logs. Rollback path: branches retrieve undo logs using XID and branch_id, verify after‑image consistency, generate compensation SQL from the before‑image, execute it, and delete the undo logs.

AT mode uses a global lock to guarantee write isolation; read isolation defaults to read‑uncommitted, but SELECT FOR UPDATE can enforce read‑committed isolation via global locking.

4. Conclusion

All discussed solutions—2PC, 3PC, TCC, transaction‑status‑table, and Seata AT mode—share the core idea of a coordinator orchestrating local transactions to achieve global ACID. While some solutions sacrifice strict XA compliance for performance or simplicity, they illustrate the engineering trade‑offs involved in building reliable distributed systems.

start global_trx
call inventory service to deduct stock
call order service to create order
commit global_trx