How Alibaba’s Fescar Tackles Distributed Transactions in Microservices

Alibaba has open‑sourced the Global Transaction Service (GTS) under the name Fescar , aiming to solve distributed‑transaction problems in microservice architectures.

1. What is the distributed‑transaction problem caused by microservices?

Microservices split a monolithic application into several loosely coupled services, reducing development difficulty and improving scalability. However, a single business operation may now involve multiple services and databases, making distributed transactions a major obstacle.

In a monolithic app, a single local transaction guarantees data consistency. After splitting into microservices, each service maintains its own local transaction, but global consistency requires a distributed‑transaction solution.

When the three modules become three independent services with separate data sources, the global transaction must coordinate them.

2. Development history of Fescar

Alibaba was among the first Chinese companies to adopt microservices and thus faced distributed‑transaction challenges early.

2014: Release of TXC (Taobao Transaction Constructor) for internal distributed transactions.

2016: TXC productized as GTS (Global Transaction Service) on Alibaba Cloud.

2019: Based on TXC and GTS, the open‑source project Fescar (Fast & Easy Commit And Rollback) was launched.

2.1 Design goals

Non‑intrusive to business : The transaction logic should be handled at the middleware layer without requiring application code changes.

High performance : The added overhead should be minimal so that transaction handling does not degrade service availability.

2.2 Why existing solutions are insufficient

Existing solutions fall into two categories:

Business‑non‑intrusive solutions

Only XA‑based solutions are non‑intrusive, but they suffer from three problems:

Require databases that support XA; many databases (e.g., older MySQL) do not.

XA locks resources for a long period, leading to poor performance.

Typically rely on heavyweight application servers (Tuxedo, WebLogic, WebSphere) unsuitable for microservices.

Business‑intrusive solutions

Approaches such as reliable‑message eventual consistency, TCC, and Saga require developers to design forward and reverse idempotent APIs, increasing development and maintenance costs.

2.3 What an ideal solution should look like

An ideal distributed‑transaction solution should be as easy to use as a local transaction, allowing developers to focus solely on business logic without dealing with transaction mechanics.

3. Principles and design

3.1 Defining a distributed transaction

A distributed transaction is a global transaction that coordinates multiple branch transactions, each of which is a local ACID transaction.

3.2 Components

Transaction Coordinator (TC) : Maintains the state of the global transaction and drives commit/rollback.

Transaction Manager (TM) : Starts a global transaction and issues the final decision.

Resource Manager (RM) : Registers branch transactions, reports status, and executes commit or rollback as instructed by TC.

3.3 Typical transaction flow

TM requests TC to start a global transaction, receiving a unique XID.

The XID is propagated through the service call chain.

RM registers its branch transaction with TC under the XID.

TM asks TC to commit or rollback the global transaction.

TC coordinates all branches to complete the commit or rollback.

3.4 Differences from XA

Architecture layer

In XA, the RM resides in the database itself, requiring database‑level XA support. Fescar’s RM is a middleware component deployed alongside the application, eliminating the need for database XA support.

Two‑phase commit optimization

XA holds locks until Phase 2 completes. Fescar allows Phase 1 to commit the local transaction and release locks early, improving concurrency for the majority of successful transactions.

3.5 Branch transaction commit and rollback

Fescar provides a JDBC proxy that records a rollback log together with the business update in the same local transaction (Phase 1). If the global decision is commit, the branch is already committed; if rollback, the RM uses the log to generate reverse SQL and undo the changes.

3.6 Transaction propagation

The global XID is passed through the RPC context of the microservice framework (e.g., Dubbo Filter + RpcContext), allowing any framework to support transparent propagation.

3.7 Supported propagation attributes

PROPAGATION_REQUIRED (default)

PROPAGATION_SUPPORTS (default)

PROPAGATION_MANDATORY (via API)

PROPAGATION_REQUIRES_NEW (via API)

PROPAGATION_NOT_SUPPORTED (via API)

PROPAGATION_NEVER (via API)

PROPAGATION_REQUIRED_NESTED (not supported)

3.8 Isolation

Global isolation builds on the local transaction isolation level. Fescar uses a global write‑exclusive lock maintained by TC, defaulting to READ‑UNCOMMITTED for high efficiency while still supporting READ‑COMMITTED when needed.

4. Application scenarios

4.1 AT (Automatic Transaction) mode

Business code does not need to handle transaction logic; the framework automatically manages branch registration, status reporting, commit, and rollback.

4.2 MT (Manual Transaction) mode

Developers split business logic into Prepare/Commit/Rollback phases, allowing non‑transactional resources to participate in the global transaction.

4.3 Mixed mode

AT and MT branches can coexist in the same global transaction, enabling full coverage of scenarios where AT alone is insufficient.

5. Extension points

5.1 Microservice framework support

Developers can contribute support for frameworks beyond Dubbo by implementing XID propagation.

5.2 Supported databases

AT mode requires SQL parsing; currently MySQL is supported, and contributors can add other databases.

5.3 Configuration and service‑discovery

Fescar can integrate with Nacos, Eureka, ZooKeeper, etc.

5.4 MT mode extensions

MT mode can wrap non‑relational resources such as Redis, HBase, RocketMQ, bringing them under global transaction management.

5.5 Transaction coordinator high‑availability

Various HA designs are possible, e.g., file‑based or database‑based state persistence, RPC‑based or KV‑store‑based cluster synchronization.

6. Roadmap

Blueprint

Green parts are already open‑sourced; yellow parts are upcoming releases; blue parts are community‑driven.

v0.1.0

Microservice framework: Dubbo

Database: MySQL

Spring AOP annotation support

Single‑node transaction coordinator

v0.5.x

Microservice framework: Spring Cloud

MT mode

TCC transaction adaptation

Dynamic configuration and service discovery

HA coordinator cluster

v0.8.x

Metrics

Console for monitoring, deployment, scaling

v1.0.0

General Availability for production

v1.5.x

Database support: Oracle, PostgreSQL, OceanBase

Annotation‑free usage

Hot‑data optimization

RocketMQ transactional messages

NoSQL integration (HBase, Redis)

v2.0.0

Native XA support

Community feedback will continuously shape the roadmap.

Related links

Fescar on GitHub: https://github.com/alibaba/fescar

GTS on Alibaba Cloud: https://help.aliyun.com/product/48444.html