seadt: A Golang Distributed Transaction Framework for Financial Products

seadt is a distributed transaction solution built with Golang for Shopee's Financial Products team. It addresses the lack of mature middleware in the Go ecosystem for handling distributed transactions in high‑risk financial scenarios.

The article introduces the challenges of distributed transactions in loan processing, such as ensuring consistency between coupon freezing and credit limit freezing, and outlines the need for a robust solution.

Four transaction models are evaluated (AT, TCC, Saga, XA). After analysis, the team selects the TCC model because it does not depend on underlying database transaction support and provides clear two‑phase commit semantics.

Four technical options are compared: seata‑go‑server, seata‑golang, internal solutions, and a self‑developed framework. The self‑developed approach wins due to active maintenance, strong internal expertise, and the ability to tailor the framework to Shopee’s regulatory and performance requirements.

The architecture consists of a global Transaction Coordinator (TC) deployed as a separate service, Transaction Managers (TM) embedded in each business module, and Resource Managers (RM) that handle local resources. All modules import the seadt‑SDK, which provides TM, RM, and a reliable‑event manager to guarantee eventual consistency.

The TC operates in a global mode, handling registration of global transactions, coordinating two‑phase commit/rollback, and supporting future Saga extensions. Detailed state‑machine diagrams illustrate the main transaction states (Prepared, Tried, Committed, Rollbacking, Canceled) and the interaction matrix between main and branch transactions.

Key constraints and best‑practice guidelines are defined for initiators, participants, and the TC, covering atomic commitment properties, idempotency, empty commit/rollback handling, monitoring, and data isolation.

Technical challenges include implementing AOP‑style interception in Go for automatic branch registration and idempotency, designing a protocol‑agnostic TC‑to‑RM communication layer, and ensuring high availability of the TC service.

The framework is already deployed in core loan‑processing flows, significantly reducing custom transaction code. Future work will add Saga support and further documentation.

AC1: All participants that decide reach the same decision.
AC2: If any participant decides COMMIT, then all participants must have voted YES.
AC3: If all participants vote YES and no failures occur, then all participants decide COMMIT.
AC4: Each participant decides at most once (that is, a decision is irreversible).
A protocol that satisfies all four of the above properties is called an atomic commitment protocol.
—— Ozalp Babaoglu, Understanding Non‑Blocking Atomic Commitment, Jan 1993