Apache Seata Turns Distributed Transaction Nightmares into Spring Boot Dreams

In a time when nostalgia may have gone a little too far, the software development world has been swept by a heated debate: has the massive adoption of the microservicespattern truly delivered the expected benefits, or is its balance sheet more uncertain? Many teams are starting to wonder whether it’s time for a “homecoming” to the good old, reliable monolith — or if the answer lies somewhere in between, in the form of the modular monolith.Excluding the cost factor, this rethinking often stems from the inherent complexity of distributed systems, particularly one of their crucial pain points:distributed transactions.This article aims to address precisely this topic, demonstrating howApache Seata, in this case combined with the agility of Spring Boot, manages to transform what for many is a nightmare into a surprisingly manageable solution. I will show you how Seata can help you sleep soundly at night, eliminating the need for complex architectures and rollback strategies and/or resorting to more cumbersome patterns like the Outbox pattern. microservices distributed transactions Apache Seata Outbox pattern Apache Seata Apache Seata is an open source distributed transaction solution, currently in Apache incubation, that delivers high performance and easy to use distributed transaction services under a microservices architecture. Apache Seata Apache Seata Apache incubation Apache incubation The main components are: Transaction Coordinator (TC): maintain status of global and branch transactions, drive the global commit or rollback. Transaction Manager (TM): define the scope of global transaction: begin a global transaction, commit or rollback a global transaction. Resource Manager (RM): manage resources that branch transactions working on, talk to TC for registering branch transactions and reporting status of branch transactions, and drive the branch transaction commit or rollback. Transaction Coordinator (TC): maintain status of global and branch transactions, drive the global commit or rollback. Transaction Coordinator TC Transaction Manager (TM): define the scope of global transaction: begin a global transaction, commit or rollback a global transaction. Transaction Manager TM Resource Manager (RM): manage resources that branch transactions working on, talk to TC for registering branch transactions and reporting status of branch transactions, and drive the branch transaction commit or rollback. Resource Manager The supported transaction models are: AT, XA (2PC) and SAGA. AT XA (2PC) SAGA. (If you’d rather skip the theory, go straight to the practical solution!) XA (2PC) XA is a specification released in 1991 by X/Open (which later merged with The Open Group). Phase 1: Prepare (Commit Vote): Phase 1: Prepare (Commit Vote): Phase 1: Prepare (Commit Vote): **TC (**Seata Server), asks all participating RMs (e.g., your microservices interacting with databases) if they are ready to commit their local transaction. Each RM performs its operations, writes transaction logs to ensure durability, and locks resources to guarantee isolation. If an RM is ready, it responds “Yes” to the TC. If not, it responds “No”. **TC (**Seata Server), asks all participating RMs (e.g., your microservices interacting with databases) if they are ready to commit their local transaction. RM Each RM performs its operations, writes transaction logs to ensure durability, and locks resources to guarantee isolation. locks resources If an RM is ready, it responds “Yes” to the TC. If not, it responds “No”. 2. Phase 2: Commit or Rollback: 2. Phase 2: Commit or Rollback: If all RMs respond “Yes”, the TC sends a “Commit” command to all RMs. They finalize their local transactions and release locks. If any RM responds “No”, or if the TC detects a timeout/failure, the TC sends a “Rollback” command. All RMs undo their operations and release locks. If all RMs respond “Yes”, the TC sends a “Commit” command to all RMs. They finalize their local transactions and release locks. all If any RM responds “No”, or if the TC detects a timeout/failure, the TC sends a “Rollback” command. All RMs undo their operations and release locks. any Pros & Cons (Briefly): Pros & Cons (Briefly): Pro: Provides strong data consistency (ACID) across multiple services, acting like a single, unbreakable transaction. Con: Can lead to resource blocking (high latency) if participants or the coordinator are slow or fail, potentially impacting availability and scalability. It also relies on underlying databases/resources supporting the XA standard. Pro: Provides strong data consistency (ACID) across multiple services, acting like a single, unbreakable transaction. Pro: strong data consistency (ACID) Con: Can lead to resource blocking (high latency) if participants or the coordinator are slow or fail, potentially impacting availability and scalability. It also relies on underlying databases/resources supporting the XA standard. Con: resource blocking (high latency) SAGA The SAGA pattern is a widely adopted approach in microservices architectures to manage distributed transactions. Unlike 2PC, Saga sacrifices immediate strong consistency for higher availability and scalability, achieving eventual consistency. A Saga is a sequence of local transactions, where each local transaction (within a single microservice) updates its own database and then publishes an event or message to trigger the next local transaction in the sequence. local transactions No Global Locks: crucially, local transactions commit immediately and do not hold global locks, allowing for greater concurrency. Compensation for Failure: if any local transaction fails, the Saga does not “rollback” in the traditional sense. Instead, it executes a series of compensating transactions to semantically undo the effects of previously completed local transactions. These compensating transactions are new operations designed to reverse the business impact. No Global Locks: crucially, local transactions commit immediately and do not hold global locks, allowing for greater concurrency. No Global Locks: Compensation for Failure: if any local transaction fails, the Saga does not “rollback” in the traditional sense. Instead, it executes a series of compensating transactions to semantically undo the effects of previously completed local transactions. These compensating transactions are new operations designed to reverse the business impact. Compensation for Failure: compensating transactions Saga can be implemented via: Choreography: Services publish events and react to them, leading to a decentralized flow. Orchestration: A central orchestrator service coordinates the flow, sending commands and reacting to responses. Choreography: Services publish events and react to them, leading to a decentralized flow. Choreography: Orchestration: A central orchestrator service coordinates the flow, sending commands and reacting to responses. Orchestration: Pros & Cons (Briefly): Pros & Cons (Briefly): Pro: Excellent for high availability and scalability due to lack of long-held distributed locks. Ideal for loosely coupled microservices. Con: Achieves eventual consistency, meaning data might be temporarily inconsistent. Requires significant development effort to implement all compensating transactions and manage complex Saga logic, which can also make debugging harder. Pro: Excellent for high availability and scalability due to lack of long-held distributed locks. Ideal for loosely coupled microservices. Pro: high availability and scalability Con: Achieves eventual consistency, meaning data might be temporarily inconsistent. Requires significant development effort to implement all compensating transactions and manage complex Saga logic, which can also make debugging harder. Con: eventual consistency development effort AT The AT (Automatic Transaction) Mode is Seata’s flagship solution, aiming to offer the ease-of-use of 2PC with the non-blocking nature and scalability benefits of Saga. It’s the recommended default for most microservices using relational databases. AT (Automatic Transaction) Mode ease-of-use of 2PC with the non-blocking nature and scalability benefits of Saga Phase 1: Local Transaction & Prepare: Phase 1: Local Transaction & Prepare: Phase 1: Local Transaction & Prepare: When a microservice (RM) performs a database operation (e.g., UPDATE, INSERT, DELETE) within a global transaction: Seata’s intelligent DataSourceProxy intercepts the SQL. It automatically creates an undo_log (recording the data’s state before the modification). The SQL operation is executed and committed immediately on the local database. Seata then acquires a global lock for the modified resource via the Transaction Coordinator (TC). This lock is not a traditional database lock; it prevents other global transactions from concurrently modifying the same resource, but doesn’t block read operations. The RM informs the TC that its branch transaction is “prepared.” When a microservice (RM) performs a database operation (e.g., UPDATE, INSERT, DELETE) within a global transaction: Seata’s intelligent DataSourceProxy intercepts the SQL. DataSourceProxy It automatically creates an undo_log (recording the data’s state before the modification). undo_log before The SQL operation is executed and committed immediately on the local database. committed immediately Seata then acquires a global lock for the modified resource via the Transaction Coordinator (TC). This lock is not a traditional database lock; it prevents other global transactions from concurrently modifying the same resource, but doesn’t block read operations. global lock not concurrently modifying the same resource The RM informs the TC that its branch transaction is “prepared.” 2. Phase 2: Global Commit or Rollback: 2. Phase 2: Global Commit or Rollback: Global Commit: If all branch transactions prepare successfully, the TC instructs them to commit. Since local DB transactions were already committed in Phase 1, RMs simply release their global locks. Global Rollback: If any branch transaction fails, or the global transaction needs to rollback: The TC instructs the RMs to roll back. RMs use their stored undo_log to automatically compensate for the changes made to their local databases, effectively restoring the previous state. They then release their global locks. Global Commit: If all branch transactions prepare successfully, the TC instructs them to commit. Since local DB transactions were already committed in Phase 1, RMs simply release their global locks. Global Commit: Global Rollback: If any branch transaction fails, or the global transaction needs to rollback: Global Rollback: The TC instructs the RMs to roll back. RMs use their stored undo_log to automatically compensate for the changes made to their local databases, effectively restoring the previous state. They then release their global locks. undo_log automatically compensate Pros & Cons (Briefly): Pros & Cons (Briefly): Pro: Provides strong consistency for the global transaction. Offers excellent availability and scalability as local database locks are held only briefly. It’s highly transparent to developers, requiring minimal code changes. Automatic rollback simplifies error handling. Con: Primarily designed for relational databases. While non-blocking at the DB level, there’s still an overhead from generating undo_logs and managing global locks. Pro: Provides strong consistency for the global transaction. Offers excellent availability and scalability as local database locks are held only briefly. It’s highly transparent to developers, requiring minimal code changes. Automatic rollback simplifies error handling. Pro: strong consistency excellent availability and scalability transparent to developers Con: Primarily designed for relational databases. While non-blocking at the DB level, there’s still an overhead from generating undo_logs and managing global locks. Con: relational databases A practical demonstration with Spring Boot Let’s envision a scenario involving two distinct microservices, each operating with its own dedicated and autonomous database: two distinct microservices Credit API: responsible for managing user credit (money balance) Shipping API: dedicated to handling shipment purchases Credit API: responsible for managing user credit (money balance) Credit API Shipping API: dedicated to handling shipment purchases Shipping API Orchestrating these two services is a BFF (Backend For Frontend). Its role is to coordinate the shipment purchase operation, which translates into a sequence of distributed calls: BFF (Backend For Frontend) Checking and/or deducting user credit via the Credit API. Actually purchasing the shipment using the credit, via the Shipping API. Checking and/or deducting user credit via the Credit API. Checking and/or deducting user credit Actually purchasing the shipment using the credit, via the Shipping API. Actually purchasing the shipment The crucial question then arises: how can we ensure that these operations, distributed across different services and databases, maintain their transactional consistency, guaranteeing that the purchase is completed only if the credit has been successfully updated, and vice-versa? transactional consistency Architecture TM TM The BFF will represent the Transaction Manager, i.e. it will define the global transaction. @Service public class BFFManager { @Autowired private CreditService creditService; @Autowired private ShippingService shippingService; @GlobalTransactional public ShippingResult buyShipping(Long userID, BigDecimal cost) { var wallet = creditService.updateBalance(userID, cost); var shipping = shippingService.buyShipping(userID, cost); wallet = creditService.getWallet(userID); var result = new ShippingResult(); result.setCost(cost); result.setShippingID(shipping.getId()); result.setCurrentBalance(wallet.getBalance()); return result; } } @Service public class BFFManager { @Autowired private CreditService creditService; @Autowired private ShippingService shippingService; @GlobalTransactional public ShippingResult buyShipping(Long userID, BigDecimal cost) { var wallet = creditService.updateBalance(userID, cost); var shipping = shippingService.buyShipping(userID, cost); wallet = creditService.getWallet(userID); var result = new ShippingResult(); result.setCost(cost); result.setShippingID(shipping.getId()); result.setCurrentBalance(wallet.getBalance()); return result; } } So just the @GlobalTransactional annotation is enough? Of course not, but little else is needed: @GlobalTransactional Dependencies needed for TM: implementation 'org.apache.seata:seata-spring-boot-starter:2.3.0' implementation('com.alibaba.cloud:spring-cloud-starter-alibaba-seata:2023.0.3.3') { exclude group: 'org.apache.seata', module: 'seata-spring-boot-starter' } implementation 'org.apache.seata:seata-spring-boot-starter:2.3.0' implementation('com.alibaba.cloud:spring-cloud-starter-alibaba-seata:2023.0.3.3') { exclude group: 'org.apache.seata', module: 'seata-spring-boot-starter' } spring-cloud-starter-alibaba-seata, among other things it can do, ensures that http communications between microservices always contain the Global Transaction ID (XID). spring-cloud-starter-alibaba-seata Global Transaction ID XID seata-spring-boot-starter is the classic Spring Boot starter that autoconfigures the Seata entity (in this case the TM) starting from the properties: seata-spring-boot-starter seata: enabled: true data-source-proxy-mode: AT enable-auto-data-source-proxy: true application-id: ${spring.application.name} tx-service-group: default_tx_group service: vgroup-mapping: default_tx_group: default grouplist: default: 127.0.0.1:8091 seata: enabled: true data-source-proxy-mode: AT enable-auto-data-source-proxy: true application-id: ${spring.application.name} tx-service-group: default_tx_group service: vgroup-mapping: default_tx_group: default grouplist: default: 127.0.0.1:8091 RM RM credit-api and shipping-api act as RM. They only need dependency seata-spring-boot-starter with following properties: credit-api shipping-api seata-spring-boot-starter seata: enabled: true data-source-proxy-mode: AT enable-auto-data-source-proxy: true application-id: ${spring.application.name} tx-service-group: default_tx_group service: vgroup-mapping: default_tx_group: default grouplist: default: 127.0.0.1:8091 seata: enabled: true data-source-proxy-mode: AT enable-auto-data-source-proxy: true application-id: ${spring.application.name} tx-service-group: default_tx_group service: vgroup-mapping: default_tx_group: default grouplist: default: 127.0.0.1:8091 It is necessary that the RM DB contains the undo_log table for Seata. Here are the necessary scripts for each type of DB. undo_log Here Here In the code that you will find on GitHub the creation of the table is managed through the docker compose that creates the dedicated db (through org.springframework.boot:spring-boot-docker-compose) In the code that you will find on GitHub the creation of the table is managed through the docker compose that creates the dedicated db (through org.springframework.boot:spring-boot-docker-compose) In the code that you will find on GitHub the creation of the table is managed through the docker compose that creates the dedicated db (through org.springframework.boot:spring-boot-docker-compose) In RMs, no specific annotation is needed. Write your code towards the repository as you always have. If you want, and I recommend it, continue to use @Transactional for local transactions. @Transactional TC TC The TC is represented by the heart of Seata, seata-server. This requires two main configurations: seata-server. Registry: defines the Service Registry that Seata will use (nacos, eureka, consul, zookeper, redis, file). For this example I chose to use the file type Store: defines the persistence of global transaction data and global locks (file, db, redis). For this example I chose to use db type. Registry: defines the Service Registry that Seata will use (nacos, eureka, consul, zookeper, redis, file). For this example I chose to use the file type Service Registry file Store: defines the persistence of global transaction data and global locks (file, db, redis). For this example I chose to use db type. db Here’s the docker compose setup used to initialize the server: services: mysql: image: mysql:8.0.33 container_name: mysql-seata environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: seata MYSQL_USER: seata_user MYSQL_PASSWORD: seata_pass ports: - "3317:3306" volumes: - mysql_data:/var/lib/mysql - ./docker/seata/mysql.sql:/docker-entrypoint-initdb.d/seata.sql:ro healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-prootpass"] interval: 10s timeout: 5s retries: 5 seata-server: image: apache/seata-server:2.3.0 container_name: seata-server depends_on: mysql: condition: service_healthy environment: - SEATA_CONFIG_NAME=application.yml volumes: - "./docker/seata/resources/application.yml:/seata-server/resources/application.yml" - "./docker/seata/mysql-connector-j-8.0.33.jar:/seata-server/libs/mysql-connector-j-8.0.33.jar" ports: - "7091:7091" - "8091:8091" volumes: mysql_data: services: mysql: image: mysql:8.0.33 container_name: mysql-seata environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: seata MYSQL_USER: seata_user MYSQL_PASSWORD: seata_pass ports: - "3317:3306" volumes: - mysql_data:/var/lib/mysql - ./docker/seata/mysql.sql:/docker-entrypoint-initdb.d/seata.sql:ro healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-prootpass"] interval: 10s timeout: 5s retries: 5 seata-server: image: apache/seata-server:2.3.0 container_name: seata-server depends_on: mysql: condition: service_healthy environment: - SEATA_CONFIG_NAME=application.yml volumes: - "./docker/seata/resources/application.yml:/seata-server/resources/application.yml" - "./docker/seata/mysql-connector-j-8.0.33.jar:/seata-server/libs/mysql-connector-j-8.0.33.jar" ports: - "7091:7091" - "8091:8091" volumes: mysql_data: And the configuration properties (application.yaml): application.yaml server: port: 7091 spring: application: name: seata-server datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://mysql:3306/seata username: seata_user password: seata_pass logging: config: classpath:logback-spring.xml file: path: ${log.home:${user.home}/logs/seata} console: user: username: seata password: seata seata: security: secretKey: seata tokenValidityInMilliseconds: 1800000 config: type: file registry: type: file store: mode: db db: dbType: mysql driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://mysql:3306/seata user: seata_user password: seata_pass min-conn: 10 max-conn: 100 global-table: global_table branch-table: branch_table lock-table: lock_table distributed-lock-table: distributed_lock vgroup-table: vgroup_table query-limit: 1000 max-wait: 5000 server: port: 7091 spring: application: name: seata-server datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://mysql:3306/seata username: seata_user password: seata_pass logging: config: classpath:logback-spring.xml file: path: ${log.home:${user.home}/logs/seata} console: user: username: seata password: seata seata: security: secretKey: seata tokenValidityInMilliseconds: 1800000 config: type: file registry: type: file store: mode: db db: dbType: mysql driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://mysql:3306/seata user: seata_user password: seata_pass min-conn: 10 max-conn: 100 global-table: global_table branch-table: branch_table lock-table: lock_table distributed-lock-table: distributed_lock vgroup-table: vgroup_table query-limit: 1000 max-wait: 5000 As you may have noticed, the dedicated database needs a number of tables to function. All the creation sql scripts are available here. here here Play! @SpringBootTest public class GlobalTransactionalTest { @Autowired private BFFManager bffManager; @Autowired private CreditService creditService; @MockitoBean private ShippingService shippingService; @Test public void globalTransactionalTest_OK() { var wallet = creditService.getWallet(1L); var shipping = new Shipping(); shipping.setId(2L); when(shippingService.buyShipping(1L, new BigDecimal(4))).thenReturn(shipping); bffManager.buyShipping(1L, new BigDecimal(4)); var newWallet = creditService.getWallet(1L); assertEquals(new BigDecimal("4.00"), wallet.getBalance().subtract(newWallet.getBalance())); } @Test public void globalTransactionalTest_KO() { var wallet = creditService.getWallet(1L); var shipping = new Shipping(); shipping.setId(2L); when(shippingService.buyShipping(1L, new BigDecimal(4))).thenThrow(new RuntimeException()); try { bffManager.buyShipping(1L, new BigDecimal(4)); } catch (Exception e) {} var newWallet = creditService.getWallet(1L); assertEquals(newWallet.getBalance(), wallet.getBalance()); } } @SpringBootTest public class GlobalTransactionalTest { @Autowired private BFFManager bffManager; @Autowired private CreditService creditService; @MockitoBean private ShippingService shippingService; @Test public void globalTransactionalTest_OK() { var wallet = creditService.getWallet(1L); var shipping = new Shipping(); shipping.setId(2L); when(shippingService.buyShipping(1L, new BigDecimal(4))).thenReturn(shipping); bffManager.buyShipping(1L, new BigDecimal(4)); var newWallet = creditService.getWallet(1L); assertEquals(new BigDecimal("4.00"), wallet.getBalance().subtract(newWallet.getBalance())); } @Test public void globalTransactionalTest_KO() { var wallet = creditService.getWallet(1L); var shipping = new Shipping(); shipping.setId(2L); when(shippingService.buyShipping(1L, new BigDecimal(4))).thenThrow(new RuntimeException()); try { bffManager.buyShipping(1L, new BigDecimal(4)); } catch (Exception e) {} var newWallet = creditService.getWallet(1L); assertEquals(newWallet.getBalance(), wallet.getBalance()); } } The complete and working code is available on GitHub. Run the components and let me know what you think! working GitHub GitHub Key alternatives Atomikos: XA (2PC). It only works within the same microservice that accesses multiple databases (there is no Transaction Coordinator, no XID propagation) Workflow engine for SAGA orchestration (Camunda, Temporal.io): requires external orchestrator and higher integration effort. SAGA (choreography event-driven): eventual consistency trade-off. Outbox pattern: eventual consistency. Atomikos: XA (2PC). It only works within the same microservice that accesses multiple databases (there is no Transaction Coordinator, no XID propagation) Atomikos Atomikos Workflow engine for SAGA orchestration (Camunda, Temporal.io): requires external orchestrator and higher integration effort. Camunda Camunda Temporal.io Temporal.io SAGA (choreography event-driven): eventual consistency trade-off. Outbox pattern: eventual consistency. This article does not aim to promote Apache Seata over the other alternatives mentioned, but rather to highlight its ease of use. As always, the right tool should be chosen based on the specific context and system requirements. ease of use Next episode: “How cool were the monoliths?” Stay tuned. How cool were the monoliths?”