Seata’s Evolution: From Alibaba’s TXC to Open‑Source Transaction Framework

Seata Development History

The author began addressing Alibaba Group’s internal distributed transaction problems in 2014, creating a middleware called TXC (Taobao Transaction Constructor) that supports a non‑intrusive AT mode and a TCC mode. TXC was widely used within Alibaba to ensure consistency across multiple databases under the HSF service framework.

In 2016 the product was offered as a cloud service named GTS (Global Transaction Service) for large private‑cloud and public‑cloud customers.

In January 2019 Alibaba’s middleware team released an open‑source version called Fescar (Fast & Easy Commit And Rollback) and collaborated with the community to build a distributed transaction solution. The vision of Fescar is to make distributed transactions as simple and efficient as local transactions.

After Ant Financial joined the community, Fescar was renamed Seata (Simple Extensible Autonomous Transaction Architecture). Although Seata now includes multiple transaction modes, the AT mode remains the most attractive to customers because it moves from intrusive to non‑intrusive approaches, improving development efficiency.

Seata quickly became a popular project on GitHub, accumulating over 20,000 stars and 6,000 forks by August 2021, and continues to be a mainstream distributed transaction solution.

Seata Overall Architecture

Seata’s codebase is relatively small and its directory structure is simple.

Module Composition

The directory structure is shown below.

The modules are described as follows:

all： Only a pom file that specifies which packages Seata depends on.

bom： Only a pom file that defines Seata’s dependency management (the section).

changes： Describes version changes.

common： General utilities, thread tools, exceptions, class loading, etc.

compressor： Compression module supporting formats such as Zip, Gzip, 7z, Lz4, Bzip2.

config： Configuration module for connecting to and operating various configuration centers (Nacos, Apollo, Etcd, Consul, ZooKeeper, etc.).

core： Core module defining RPC, Netty, events, protocols, transaction context, etc.

discovery： Service discovery module supporting registration centers like Nacos, Etcd, Eureka, Redis, ZooKeeper.

distribution： Packaging module.

integration： Integration module that adapts Seata to various RPC frameworks (Dubbo, gRPC, SOFA‑RPC).

metrics： Metrics module for collecting runtime data and exporting to monitoring systems such as Prometheus.

rm： Resource Manager module defining common components for AT, TCC, Saga, and XA resource managers.

rm-datasource： AT mode resource manager implementing data‑source proxy and SQL handling; also includes XA support.

saga： Saga mode resource manager.

script： Script module containing required script and configuration files.

seata-spring-boot-starter： Starter for simplifying integration with Spring Boot.

serializer： Serialization module supporting Seata’s private protocol, FST, Hessian, Kryo, etc.

server： Server module implementing the transaction coordinator, maintaining global and branch transaction states, and driving two‑phase commit/rollback.

spring： Spring support module defining Seata transaction annotations.

sqlparser： SQL parsing module using Druid.

style： Code style definitions.

tcc： TCC mode resource manager.

test： Test module.

tm： Transaction Manager module defining global transaction scope, start, commit, and rollback.

Logical Structure

Seata has three main roles: TM (Transaction Manager), RM (Resource Manager), and TC (Transaction Coordinator).

TM and RM are SDKs integrated with business systems, while TC is a standalone server.

TM

Transaction Manager. Interacts with TC to begin, commit, or roll back global transactions.

RM

Resource Manager. Interacts with TC to handle resource‑related processing, including branch transaction registration and status reporting.

TC

Transaction Coordinator. Maintains the state of global and branch transactions and drives the two‑phase processing. For AT‑mode branch transactions, TM handles concurrency control.

Seata’s distributed transaction processing flow is illustrated below.

(1) TM starts a global transaction (TM → TC).

(2) Participants register branch transactions via RM (RM → TC).

(3) After resource operations, participants report branch status (RM → TC).

(4) TM ends the global transaction, completing the first phase (TM → TC).

(5) TC drives the second‑phase actions (TC → RM).

Seata Transaction Modes

Seata supports four transaction modes: AT, TCC, Saga, and XA. The following sections give a brief overview; later chapters will dive deeper into AT and TCC.

AT Mode

AT mode is Seata’s primary solution, offering non‑intrusive distributed transactions that separate business logic from transaction handling. Users only need to add the @GlobalTransactional annotation.

TCC Mode

TCC requires developers to implement three methods— try(), confirm(), and cancel(). The framework registers each TCC service as a resource, scans for interfaces, and intercepts calls to register branch transactions and report status.

During the first phase, each try() call registers a branch transaction, executes business logic, and reports the status to TC. After the request chain completes, the initiator notifies TC to commit or roll back, triggering TC to invoke the corresponding confirm() or cancel() on the TCC resource.

The main complexity lies in implementing the TCC service interfaces.

Key differences between TCC and AT:

AT is non‑intrusive, requiring only an annotation; TCC needs three custom methods, increasing implementation cost.

AT operates at the data‑source layer using row‑level locks; TCC operates at the application layer with custom locking.

AT’s concurrency control is automatic; TCC relies on business‑defined locking.

Example: Money Deduction

In a TCC implementation, the try() method checks balance and reserves funds (freezes amount). After try(), the balance remains unchanged but part of it is frozen.

The confirm() method actually deducts the reserved amount, reducing the balance.

If the second phase rolls back, the cancel() method releases the frozen amount, restoring the original balance.

While TCC can outperform AT in some scenarios, it generally incurs higher development effort and may not provide performance benefits; AT is recommended as the default.

Saga Mode

Saga, introduced by Hector and Kenneth in 1987, is a compensation protocol where each participant implements forward and compensating actions. The flow consists of a series of forward services (T1‑T3) and corresponding compensations (C1‑C3).

If all forward operations succeed, the transaction commits; if any fails, previously completed participants execute their compensating actions, rolling back the transaction.

Saga is highly suitable for long‑running processes requiring eventual consistency, offering lock‑free high performance, but it lacks isolation and is less applicable than AT or TCC.

XA Mode

XA mode leverages transaction resources (databases, message services) that are XA‑aware. The resources participate directly in the two‑phase commit protocol, providing strong consistency and isolation, but at the cost of lower performance and limited adoption.

*This excerpt is taken from the book “正本清源分布式事务之Seata（全彩）”.