Optimizing Distributed Transactions with Seata in a Government Talent Housing System

The government talent housing system, co‑developed by the Beike CTO line Guangzhou R&D center and a major internet company, manages employee points, housing resources, allocation rules, and online selection entirely online, requiring robust distributed transaction support.

During iterative development, the system introduced numerous batch‑processing scenarios, such as bulk updates of employees, houses, and waiting lists after selection, which could not rely on eventual‑consistency message queues and thus demanded real‑time cross‑service data operations.

After evaluating several distributed‑transaction solutions, the team selected Alibaba’s open‑source Seata, specifically its AT mode, as the best fit for the system’s consistency requirements.

Initial integration of Seata revealed severe performance degradation: inserting 30,000 rows without a global transaction took ~3.5 s, while with Seata AT it ballooned to ~280 s due to the overhead of global transaction control.

Optimization 1 – Query‑Lock Rewrite: Replaced inefficient "pk = ? OR pk = ? …" patterns with "IN (…)" clauses, improving MySQL query performance, and refactored the O(M·N²) loop that repeatedly called rowsIncludingPK.pkRows().size() to O(M·N) by avoiding repeated size calculations.

Optimization 2 – Rollback‑Info Compression: Compressed the large DML before‑/after‑image payload stored in Seata’s rollback info, reducing its size to about 10 % of the original and cutting insert‑time overhead by ~17 %, bringing the 30,000‑row transaction down to ~7.9 s.

Optimization 3 – JDBC Parameter Tuning: Enabled MySQL driver’s rewriteBatchedStatements=true, allowing the driver to rewrite batch inserts into a single multi‑value INSERT statement, which further reduced the 30,000‑row insert time by ~19 % to ~6.4 s.

Optimization 4 – Multithreading & Batch Splitting: Bound the Seata global transaction ID to ThreadLocal in asynchronous threads, combined with Spring Boot AOP to wait for all branch transactions before committing, and split large batches into smaller chunks (≈5,000 rows) processed in parallel, achieving a final execution time of ~3.4 s for 30,000 rows.

Through these combined optimizations, the batch‑processing time dropped from 280 s to 6.4 s (a 98 % reduction), meeting performance expectations and confirming Seata’s suitability for large‑scale, real‑time transactional workloads in production.

The improvements have been upstreamed to the Seata project via several pull requests, and Seata is now widely used across the R&D center’s systems, with ongoing monitoring and further refinements planned.