XA vs TCC: Which Distributed Transaction Model Fits Your Architecture?

XA Protocol Application Scenarios

XA operates at the resource manager (RM) layer. It provides a universal two‑phase commit protocol that is largely transparent to business logic but must obey the ACID properties.

Global isolation is achieved by relying on each RM’s local transaction isolation, typically the serializable level. Under serializable isolation even read‑only SELECT statements acquire read locks, which increases lock‑hold time and reduces concurrency.

Even with lock‑free global reads (e.g., distributed MVCC), the throughput of hotspot data in a distributed transaction cannot exceed that of a single‑node local transaction. XA’s main benefit is horizontal scaling of database resources while preserving ACID guarantees.

Example: a single RM can process 100 TPS for non‑hotspot data. A cluster of five RMs can theoretically deliver 500 TPS. If an average distributed transaction touches two RMs, the effective throughput is 250 TPS (2.5× improvement for non‑hotspot workloads).

Thus XA does not improve hotspot performance; it is valuable for scaling out resources and maintaining ACID across multiple databases.

TCC Model Application Scenarios

TCC (Try‑Confirm‑Cancel) works at the service layer and is independent of specific RPC frameworks or storage media. It enables fine‑grained business locks, reduces lock‑hold time, and supports asynchronous execution of the second phase.

TCC Model Advantages

Cross‑service distributed transactions – Service decomposition can be treated as horizontal resource scaling. Two scaling directions are possible:

Functional expansion: group data by business function and store each group in a separate database (SOA).

Data sharding: split data within a functional group across multiple databases.

Two‑phase split – The Try phase locks resources without blocking other transactions on the same resources; the Confirm/Cancel phase can be executed later, possibly asynchronously.

Example (Alipay guarantee transaction): the Try phase moves user funds into a pre‑frozen account (business lock). The Commit phase, executed later, transfers the funds to the merchant, reducing lock contention on the intermediate account.

Typical TCC Solutions

Generic TCC – All downstream services participate in the main service’s decision. Suitable for short‑duration, deterministic operations such as core financial services (transaction, payment, accounting). The main service invokes Try on each downstream service, then Confirm or Cancel based on the overall outcome.

Asynchronous Assurance TCC – Downstream services are decoupled via a reliable message service that provides Try, Confirm, and Cancel interfaces. The message service persists the Try payload, confirms delivery only after the main transaction succeeds, and can cancel if the main transaction fails. This pattern is appropriate for eventual‑consistency scenarios such as member registration or email notification.

Compensating TCC – Downstream services implement Do and Compensate interfaces instead of full Confirm/Cancel. Do executes the full business logic; Compensate performs an idempotent rollback. This reduces the need to modify existing services but requires careful handling of compensation failures and is best suited for low‑conflict operations (e.g., multi‑leg flight booking where external airline APIs cannot be changed).

Conclusion

Horizontal resource scaling introduces data‑consistency challenges. XA guarantees ACID at the data‑sharding level, while TCC guarantees ACID at the functional‑expansion level.

XA offers protocol‑level universality and is suitable for distributed databases and cloud‑service transaction frameworks. TCC adds two‑phase separation, enabling asynchronous execution and better handling of hotspot performance constraints.

Choosing a distributed‑transaction solution requires analysis of business requirements, performance constraints, integration complexity, and the specific characteristics of each model.