Data Consistency Strategies in Microservices: Transaction Management Patterns

Microservice architectures introduce new challenges for data consistency that cannot be fully addressed by traditional local transactions or classic distributed transaction protocols such as two‑phase commit (2PC) and three‑phase commit (3PC). The article first reviews these traditional approaches and then explains why they are unsuitable for microservices.

1. Traditional transaction management

1.1 Local transaction : In monolithic applications a single RDBMS provides ACID guarantees within a single process.

1.2 Distributed transaction : When multiple data sources are involved, protocols like 2PC and 3PC coordinate commits across resources, but they suffer from blocking, latency, and limited scalability.

2. Transaction management in microservices

Microservices cannot rely on 2PC/3PC because services communicate via RPC/HTTP, may use heterogeneous data stores (including NoSQL), and long‑running global transactions would cause severe lock contention. Instead, microservices adopt the BASE model (Basically Available, Soft state, Eventual consistency) to aim for eventual consistency.

3. Ways to achieve eventual consistency

3.1 Reliable event notification – events are persisted and delivered to downstream services.

3.1.1 Synchronous events – business logic and message sending are executed in the same flow. Example implementation:

public void trans() {
    try {
        // 1. 操作数据库
        bool result = dao.update(data); // 操作数据库失败，会抛出异常
        // 2. 如果数据库操作成功则发送消息
        if (result) {
            mq.send(data); // 如果方法执行失败，会抛出异常
        }
    } catch (Exception e) {
        roolback(); // 如果发生异常，就回滚
    }
}

Drawbacks include network failures that can leave the message sent but the transaction rolled back, and tight coupling between business and messaging services.

3.1.2 Asynchronous events – decouple business and messaging by persisting events locally first and retrying failed deliveries. Two variants are described:

Local event service : events are stored in a local table and a background worker retries delivery until success.

External event service : the event service is a separate component; the business service records the event, commits/rolls back, and the event service later sends or discards the event based on the final transaction outcome.

Both variants must handle idempotent consumption to avoid duplicate processing: 幂等性 3.2 Max‑effort notification – the producer attempts to send a message a limited number of times after committing; if all attempts fail, the message is lost and the consumer must provide a recovery query interface. This model is suitable for low‑reliability notifications such as third‑party callbacks.

3.3 Business compensation – the upstream service proceeds normally, and if a downstream service fails, the upstream service performs a compensating action (e.g., cancel a previously booked ticket). Compensation is usually only partial ( 不完全补偿) and leaves a trace of the cancelled operation.

3.4 TCC (Try‑Confirm‑Cancel) – an enhanced compensation pattern that achieves full compensation. The workflow consists of:

Try: perform checks and reserve resources (e.g., freeze funds).

If all Try phases succeed, Confirm: finalize the operation using the reserved resources.

If any Try fails, Cancel: release the reserved resources.

Example SQL for a money transfer between two banks:

try:  update cmb_account set balance=balance-100, freeze=freeze+100 where acc_id=1 and balance>100;
confirm: update cmb_account set freeze=freeze-100 where acc_id=1;
cancel:  update cmb_account set balance=balance+100, freeze=freeze-100 where acc_id=1;

try:  update cgb_account set freeze=freeze+100 where acc_id=1;
confirm: update cgb_account set balance=balance+100, freeze=freeze-100 where acc_id=1;
cancel:  update cgb_account set freeze=freeze-100 where acc_id=1;

3.5 Summary – the article compares the four common patterns (reliable sync/async events, max‑effort notification, business compensation, and TCC) and highlights their trade‑offs in terms of consistency, availability, complexity, and coupling.