Mastering Distributed Transactions with Seata: AT and TCC Modes Explained

Background

As microservice architectures evolve, monolithic applications are split into multiple services, and data is stored across several databases and storage media. A single business operation that previously required one local transaction now often needs coordinated calls to multiple services, making traditional local transactions insufficient to guarantee data consistency.

For example, an order‑placement workflow involves Order Service, Account Service, and Inventory Service. If the inventory update fails, the local transaction in the inventory service rolls back, but the order and account records remain, leading to inconsistency.

In high‑consistency scenarios, teams often resort to manual checks or AI‑assisted debugging, which are slow and error‑prone. Therefore, a reliable, generic distributed‑transaction solution is essential.

Requirements and Technology Selection

To handle growing business and data scale, mainstream solutions rely on horizontal node expansion for both application and data layers:

Expand functional nodes by refactoring applications into microservices.

Expand data nodes via sharding (database/table splitting) and hybrid storage such as MySQL + Elasticsearch.

However, this introduces data‑inconsistency problems. Two opposing views exist: some consider distributed transactions too costly and ignore them, while others pursue complex, custom solutions that lack robustness.

The industry needs a standard, generic, and reliable distributed‑transaction solution that ensures data consistency without excessive resource consumption.

Open‑Source Distributed Transaction Solutions

Common open‑source projects include Seata, tcc-transaction, TX-LCN, Hmily, ByteTCC, and EasyTransaction. They offer various models such as Compensation‑TCC, Non‑intrusive‑AT, Strong‑consistency‑XA, Compensation‑SAGA, and LCN. Among them, Seata provides the most comprehensive set of capabilities and enjoys the highest community activity.

TC Cluster High Availability

Seata separates transaction participants into Transaction Coordinator (TC), Resource Manager (RM), and Transaction Manager (TM). It supports four transaction modes—TC, AT, XA, and SAGA—covering most application scenarios. The TC cluster can be dynamically switched via a configuration center, enabling high‑availability deployments.

TCC Mode

TCC requires the business side to implement three methods—Try, Confirm, and Cancel. Try checks and reserves resources, Confirm commits the business operation, and Cancel rolls back the reservation.

Because all phases are coded by the business side, TCC offers high flexibility and can handle compensation, resource‑reservation, and message‑transaction scenarios, though it demands significant development effort.

The mode works regardless of underlying database transaction support; no JDBC dependency is required.

Seata’s TCC implementation addresses classic issues such as empty rollbacks, hanging, and idempotency.

AT Mode

AT resembles an automatic‑transmission mode: developers add an annotation to methods that require a global transaction, and Seata proxies the DataSource to intercept SQL statements, adding the necessary transaction logic.

AT requires all downstream services to use JDBC‑compatible data sources; it introduces a global row lock, which may affect performance under high‑concurrency hotspot scenarios.

In low‑concurrency, complex‑logic, high‑consistency use cases, AT provides a low‑effort, high‑efficiency solution—just add the annotation after importing the dependency.

Promoting Seata Within an Organization

Strengthen technical mastery of Seata, verify its capabilities against the company’s stack, and document findings.

Conduct training, demos, and Q&A sessions to collect requirements and use‑case feedback.

Clarify Seata’s security mechanisms and adopt a minimal‑test‑unit approach for pilot validation.

Because TCC demands extensive code changes, the initial focus should be on AT, which requires minimal modifications while still exercising most of Seata’s capabilities.

Exploring AT Mode in Depth

Phase 1 – Try (Business SQL Interception)

Seata intercepts the business SQL, parses its semantics, reads the affected rows as a “before image,” executes the update, then reads the rows again as an “after image.” It generates row‑lock information and requests a lock from the TC—all within a single local transaction to guarantee atomicity.

Phase 2 – Commit

If the global transaction commits, Seata releases the row lock immediately and cleans up the before/after images, optionally using asynchronous processing for higher performance.

Phase 2 – Rollback

For a rollback, Seata restores the “before image.” Before restoration, it checks for dirty writes by comparing the current data with the “after image.” If they match, no dirty write occurred; otherwise, manual intervention is required.

AT provides a non‑intrusive distributed‑transaction solution: developers only write business SQL, and Seata handles the rest.

Compatibility Verification

Key compatibility aspects include:

RPC framework support (e.g., Dubbo) for propagating the global transaction ID (XID) across service calls.

Database middleware considerations such as single‑instance, read‑write splitting, sharding, and dynamic data‑source switching.

Typical test cases:

Batch processing validation.

Transaction isolation using Seata’s global row‑lock to prevent dirty writes and ensure read‑committed semantics.

Independent master‑database scenarios.

Read‑write separation environments.

Pilot and Safety Measures

Seata can be enabled per environment (development, testing) and disabled in production for observation.

Selective activation per request via enhanced DataSource for AT mode.

Force rollback based on business status by throwing exceptions or invoking the global‑transaction API.

Runtime switches and dynamic degradation controls are provided through configuration centers and sliding‑window thresholds.

Operational tools for monitoring, alerting, and manual termination of abnormal transactions.

Local Construction and Ongoing Operations

Integrate with the database automation platform to initialize AT‑mode tables and manage UndoLog records.

Persist and query transaction history for audit and statistics.

Provide alerting and context inspection for abnormal transactions, with the ability to terminate them manually.

Adapt TC clusters to dual‑active (active‑active) deployment patterns.

Conclusion

By deeply exploring Seata’s capabilities, conducting thorough compatibility tests, and promoting the knowledge within teams, organizations can reliably adopt a standardized distributed‑transaction solution that reduces architectural complexity, lowers development cost, and improves operational stability. Subsequent pilot projects and community contributions further solidify confidence and accelerate adoption.