Mastering Seata-go TCC: Design, Exception Handling, and Real-World Usage

Introduction

Seata is an open‑source distributed transaction framework supporting AT, TCC, SAGA and XA modes. Seata‑go is the Go language implementation that reuses the transaction coordinator (TC) logic of Seata.

Supported Modes

Seata‑go currently implements TCC and AT modes; XA is under testing and expected to be released in May; SAGA is planned for future releases.

Architecture

Seata‑go uses the getty library for TCP communication and fully implements the Seata protocol. It integrates with configuration and registry centers and can be used with third‑party frameworks such as Dubbo‑go, gRPC and GORM.

TCC Overview

TCC (Try‑Confirm‑Cancel) is a two‑phase commit protocol. In the Try phase each branch reserves resources; if all Try operations succeed the global transaction proceeds to the Confirm phase, otherwise the Cancel phase rolls back. The application must implement Try, Confirm and Cancel logic for each branch.

Core Roles

Seata defines three roles:

TC (Transaction Coordinator) – maintains global transaction state and drives commit/rollback.

TM (Transaction Manager) – initiates global transactions and orchestrates branch calls.

RM (Resource Manager) – executes resource‑specific operations (e.g., database statements) and reports branch status to TC.

TCC Workflow in Seata‑go

TM requests TC to start a global transaction; TC records the transaction ID.

TM registers a branch with each RM and invokes the Try method.

If any Try fails, TM asks TC to roll back; TC sends Rollback to all successful branches.

If all Try succeed, TM asks TC to commit; TC sends Commit to all branches.

Defining TCC Services

Seata‑go provides two ways to define a TCC service:

Implement the TwoPhaseInterface interface. This is the recommended, simpler approach.

Use a tag‑based definition, required by frameworks such as dubbo‑go, which offers more flexibility but is more complex.

Typical Usage Pattern

Define a service using one of the methods above.

Wrap the service with NewTCCServiceProxy to obtain a proxy instance.

Compose branch calls and execute the global transaction via WithGlobalTx.

Complete examples are available in the Seata‑go samples repository: https://github.com/seata/seata-go-samples.

Exception Handling

Common issues in TCC include:

Idempotency : Network delays may cause duplicate Try/Confirm calls. Business logic must be idempotent.

Empty Rollback : A Rollback may arrive before the corresponding Try, leading to unnecessary rollback work.

Hanging (Suspend) : A Rollback arrives before Try, and later a Try arrives after the global transaction has ended, leaving resources locked.

Fence Log Solution (same as Seata Java)

Seata‑go uses a tcc_fence_log table (primary key: global‑transaction‑ID + branch‑ID) to record branch state within the same local transaction as the business SQL. The record prevents duplicate Try execution and guides Commit/Cancel decisions, ensuring idempotency and handling empty rollback or suspend scenarios.

Manual Fence Implementation

Developers can implement equivalent fence logic themselves. A reference implementation is provided in the repository:

https://github.com/seata/seata-go-samples/tree/main/tcc/fence

.

Future Roadmap

Seata‑go is collaborating with Go microservice and ORM communities (e.g., GORM) and the MOSN project to build a Transaction Mesh. XA support is scheduled for May, and the next major focus is the implementation of Saga mode, including advanced workflow features such as DAG execution, scheduled tasks and batch job orchestration.