Mastering TCC: Key Design Practices for Reliable Distributed Transactions

This article introduces the TCC (Try‑Confirm‑Cancel) distributed transaction model, explains its two‑phase workflow, and outlines six essential design considerations—including two‑phase operation splitting, empty rollback handling, suspension control, idempotency, data visibility, and concurrency—while sharing Ant Financial’s decade‑long practical experience and solutions.

Java Backend Technology
Java Backend Technology
Java Backend Technology
Mastering TCC: Key Design Practices for Reliable Distributed Transactions

TCC Overview

TCC (Try‑Confirm‑Cancel) is a mature distributed transaction solution that ensures data consistency across multiple databases. It follows a service‑oriented two‑phase programming model where the business implements three methods: Try, Confirm, and Cancel.

In the first phase, the Try operation checks and reserves resources. In the second phase, the Confirm operation commits the actual business logic, while the Cancel operation releases any reserved resources if the transaction cannot be completed.

TCC workflow diagram
TCC workflow diagram

Key Design Considerations When Implementing TCC Services

Two‑Phase Business Operations : Split business logic into Try (resource check/reserve) and Confirm (actual execution) phases.

Allow Empty Rollback : The transaction coordinator may trigger a Cancel without a prior Try due to network timeouts; the service must handle such empty rollbacks gracefully.

Suspension Control : After an empty rollback, any subsequent Try requests that arrive later must be rejected to avoid out‑of‑order execution.

Idempotency : Ensure that repeated executions of Try, Confirm, or Cancel produce the same business outcome, handling retransmissions and compensations.

Data Visibility Control : During the Try phase, reserved resources are in an intermediate state; design the system to either hide or minimally expose such data to users.

Concurrent Access Control : Since reserved resources remain locked until the second phase, implement fine‑grained logical locks to maximize concurrency while preventing conflicts.

Design considerations diagram
Design considerations diagram

Conclusion

Ant Financial has deployed TCC for over ten years, accumulating extensive practical experience. Beyond the design guidelines above, they have built high‑performance, highly available distributed transaction solutions that support massive traffic spikes (e.g., Double 11). Their SOFA‑DTX framework offers additional modes—FMT and XA—that relieve users from implementing TCC services directly, allowing them to focus solely on business SQL. The three modes complement each other, forming a comprehensive distributed transaction solution used in Alipay, online banking, Ant Wealth, Sesame Credit, Nanjing Bank, and many other projects.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

tccDistributed Transactionstransaction-management
Java Backend Technology
Written by

Java Backend Technology

Focus on Java-related technologies: SSM, Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading. Occasionally cover DevOps tools like Jenkins, Nexus, Docker, and ELK. Also share technical insights from time to time, committed to Java full-stack development!

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.