Four transaction modes solve different failure problems
Seata coordinates a global transaction made of branch transactions. A transaction manager opens and closes the global scope, resource managers register the branches, and a transaction coordinator records their status and drives commit or rollback. That structure addresses a concrete failure: an order service commits while inventory or account work fails in another database. If all writes live in 1 database, the README says its local transaction is enough.
The product decision starts with 4 modes. AT proxies JDBC data sources and writes rollback information alongside business data. TCC asks the service to implement Try, Confirm, and Cancel. Saga commits local steps and runs compensating actions after a later failure. XA delegates prepare, commit, and rollback to XA-capable resources. These options share a coordinator, but their behavior under locks, long-running work, and partial failure differs enough that a team cannot treat them as interchangeable configuration flags.
What happened when we ran it
Our sandbox entered saga/seata-saga-statemachine-designer at commit 4d7ba2e. Npm installed 766 packages in 13 seconds and consumed 170 MB on a fresh Debian container with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. The production webpack build succeeded in 23 seconds, and npm audit found 0 known vulnerabilities at every reported severity.
The designer's package.json has start and build scripts but no test target, so our test step was skipped. We did not compile the Java modules, start a transaction coordinator, connect a database, or force a rollback. The result establishes that the version 3.0.0 visual Saga designer builds in that environment. It says nothing about transaction throughput, recovery time, database compatibility, or the correctness of a production compensation routine.
The full checkout held 4,041 files, about 414,478 lines of source, and used 26.1 MB before npm dependencies. Our scan counted 12 CI workflow files and reported no Dockerfile or tests directory. Seata's broader repository and documentation contain many Java tests and deployment material, but those were outside the npm target selected by this run. No Java test count or server build result should be inferred from the green 23-second designer build.
AT reduces application changes but adds rollback tables
AT is the first mode to test for conventional Java services using supported relational databases. A DataSourceProxy intercepts database work, stores an undo_log in the same local transaction as the business change, and checks a global lock. The second phase can commit asynchronously or use the saved log to compensate. A Spring service marks the boundary with @GlobalTransactional, which keeps business code closer to an ordinary local transaction.
That convenience moves work into the data layer. Every participating data source needs the proxy, AT databases need an undo_log table, and SQL plus schema compatibility must be checked against the version you deploy. Seata's current README still puts 2.5.0 in its Maven example, while GitHub lists v2.6.0 as the latest stable release. Pin the client and server together, then test the exact drivers, SQL shapes, and rollback cases used by your services.
TCC and Saga make compensation your code
TCC works above the database. Each business resource implements 3 operations: Try reserves the resource, Confirm completes it, and Cancel releases or reverses the reservation. This gives precise control and short resource-hold times, but it changes service interfaces and pushes idempotence, empty rollback, and hanging cases into the design. Use it when the business can define reservation semantics clearly, such as holding credit or stock before final confirmation.
Saga fits longer work and participants that cannot provide TCC's 3 methods. Each step commits locally, and a later failure runs compensation for completed steps. Seata's engine stores the workflow as JSON, and the visual designer we built imports and exports that state language. The official guide warns that Saga does not guarantee isolation. A compensation can restore a balance after failure, yet another process may observe the intermediate state before that repair happens.
XA keeps isolation and holds resources longer
XA uses the transaction protocol supplied by the participating database or resource. For an application, switching from AT mainly means using DataSourceProxyXA. The attraction is strong isolation without writing TCC handlers or Saga compensation graphs. The cost appears after XA prepare: the branch blocks and keeps transaction resources until the global decision reaches commit or rollback. Seata's guide describes the resulting lock cycle and performance as poor.
That makes XA a migration option for systems already designed around XA-capable databases, not a default simply because it sounds stricter. Test coordinator loss, database restart, network delay, and recovery of prepared branches. A 23-second JavaScript build offers no evidence for any of those paths. If lock duration threatens user traffic, AT or a business-level pattern may fit better, provided its weaker points are acceptable.
Production adds a coordinator, storage, and XID plumbing
The coordinator is a separate server. File storage is a standalone option, while database, Redis, and Raft modes change availability and recovery behavior. The deployment guide calls for 2 GB of heap and 1 GB of off-heap memory, then adds registry, storage, and client configuration. AT needs database tables, and every service boundary must carry the XID so branches join the same global transaction.
GitHub showed 26,011 stars, 796 open issues, 125 open pull requests, and a push on October 4, 2026. The latest stable release is v2.6.0 from January 28, while a v2.7.0 release candidate was published on September 6. That combination shows active development despite the 921-item combined queue. Seata is the serious choice when its coordinator and 4-mode design solve a known cross-service failure. Otherwise, the operational surface is larger than the transaction problem.