Understanding Distributed Transactions in Microservices: Challenges and Practical Solutions

In the era of micro‑service architectures, distributed transactions have become a long‑standing pain point. This article examines why distributed transactions are difficult, distinguishes them from consensus protocols such as Paxos/Raft, and proposes pragmatic ways to handle them.

1. Problem Overview

Distributed transactions require all sub‑operations to either succeed together or have no effect at all. The difficulty lies in the fact that each step involves a remote RPC that may fail, making the atomicity (the “A” in ACID) hard to guarantee.

2. Analysis and Discussion

(1) Timeout handling

Timeouts can leave a transaction in an indeterminate state – it may have succeeded or not. Accurate post‑mortem information is required to decide the next steps.

(2) Reconciliation (audit) capability

Each sub‑task must be traceable via a unique transaction ID so that the system can query the real execution result. This enables both idempotency and compensation.

(3) Local log persistence

Logging locally (e.g., to a file or a cloud storage) can capture the transaction flow. However, without DB‑level guarantees, additional WAL (write‑ahead log) information may be needed to record expected before‑and‑after values.

节点1完成任务1
节点2完成任务1
节点3完成任务1

In contrast, a distributed transaction bundles multiple tasks:

节点1完成任务1
节点1完成任务2
节点1完成任务3

(4) SQL‑based persistence

Using a local DB transaction together with an undo‑log table (as in Seata) allows the coordinator to query the undo‑log to determine whether a sub‑transaction succeeded.

开启本地事务
add 业务sql：具体业务逻辑对应的 sql
add undolog 表sql：insert 一条 undo log，key 包含事务 ID // 基于该表反查
提交本地事务

(5) NoSQL persistence

If the NoSQL store lacks native transactions, the transaction ID can be stored in the value as an array, enabling later reconciliation.

// 业务表示例
message ServiceTable{
repeated string txids = 1; // 事务 id 数组，按一定 size 滚存
int32 field1 = 2;
int32 field2 = 3;
int32 field3 = 4;
int32 field4 = 5;
}

(6) External interfaces

When a distributed transaction involves third‑party services, those services must also provide audit and idempotent capabilities.

(7) Typical complex micro‑service scenario

事务开启
任务1：改数据 A // sql 存储
任务2：改数据 B // nosql 存储
任务3：调用系统内服务接口 C // 可能被调服务也有事务需求
任务4：调用外部门服务接口 D
事务结束

Large‑scale systems must carefully decide which transactions truly need strict atomicity and which can tolerate eventual consistency.

(8) When DB‑level audit is unavailable

One can trade consistency for availability, e.g., using TCC with a lock held on the user’s data until the transaction fully completes.

try 阶段 lock 好
confirm commit... 直至确定 ok 为止
明确完成后才 unlock

Lock granularity, lock duration, and whether to use optimistic or pessimistic locking must be analyzed per use‑case.

Conclusion

Distributed transactions are inherently complex. Whether to adopt a full‑blown framework (Seata, TCC, Saga) or a lightweight compensation mechanism depends on the business’s consistency requirements, traffic volume, and operational cost. Properly designed transaction IDs, idempotent operations, and audit capabilities are essential prerequisites for any solution.