Solving Distributed Transaction Challenges with a Supply‑Chain Consistency Framework

1. Introduction

In the era of micro‑service architecture, distributed systems have become the standard for enterprise applications, but they bring the challenge of distributed transactions. Ensuring data consistency across logistics, inventory, and order modules is critical for efficient operation.

2. Consistency Theory Basics

Consistency models are divided into strong consistency, weak consistency, and eventual consistency. Strong consistency requires all nodes to see identical data at any moment. Weak consistency does not guarantee simultaneous data visibility. Eventual consistency, a key compromise in the CAP theorem, ensures that all nodes will converge to the same data after a period, providing high availability.

In micro‑service systems, using strong consistency often degrades availability and increases response time. Therefore, the "complete local transaction first, then asynchronously ensure remote success" approach of eventual consistency is widely adopted.

3. Overall Architecture of the Consistency Framework

The framework provides core functions such as a declarative API, operation record persistence, automatic retry, concurrency control, timeout and circuit‑breaker handling, and monitoring with alerts.

Declarative API: Simple and easy‑to‑use interfaces for developers.

Operation Record Persistence: Records operation information for retry.

Automatic Retry Mechanism: Retries failures according to configured strategies.

Concurrency Control: Prevents issues caused by concurrent retries.

Timeout and Circuit‑Breaker: Avoids resource waste from invalid retries.

Monitoring and Alerting: Alerts when retry failures exceed thresholds.

4. Implementation Principles

Core Component Design

The framework consists of annotation, interception, execution, and persistence layers.

Annotation Layer

The

@EventualConsistency

annotation is the entry point, with attributes such as

async()

,

maxRetryTimes()

,

delay()

,

listeners()

,

beanName()

,

referenceNo()

, and

serializerListener()

.

Interception Layer

AnnotationAwareRetryOperationsInterceptor

intercepts methods annotated with

@EventualConsistency

and creates execution strategies based on the annotation.

Execution Layer

Executes methods according to their state, using different executors:

SyncConsistencyExecutor: Synchronous execution in the current thread.

AsyncConsistencyExecutor: Asynchronous execution via a thread pool.

RetryConsistencyExecutor: Retries methods with exception status.

NestedConsistencyExecutor: Handles nested consistency calls, recording execution without immediate invocation.

Persistence Layer

Execution records are stored in a database (MongoDB) to avoid performance issues.

Asynchronous Execution Principle

Operations are persisted first, then executed asynchronously after the transaction commits, ensuring that async actions only run when the original transaction succeeds.

Retry Mechanism

Persisted Records: Store parameters and status of each execution.

Scheduled Scanning: Periodically scan for records needing retry.

Distributed Lock: Ensure only one instance performs retries in a cluster.

Reflection Invocation: Dynamically call target methods via reflection.

5. Domain Model

6. Data Model

7. Framework Example

When a buyer places an order in the DeWu app, the supply chain receives the shipping order. The warehouse domain notifies the fulfillment domain and deducts inventory. The consistency framework ensures that even if the fulfillment system fails, inventory deduction succeeds.

<code>public void ship(String orderCode){
    // Notify fulfillment domain
    notifyOfcShip(orderCode);
    // Deduct inventory
    inventorySubtract(orderCode);
}

@EventualConsistency(referenceNo = "#orderCode")
public void notifyOfcShip(String orderCode){
    // Call fulfillment domain for shipping
}
</code>

The framework retries the notification to the fulfillment domain if an exception occurs, guaranteeing that inventory is deducted and the shipping status is updated.

8. Conclusion

In distributed systems, a consistency framework is essential for reliability. Proper use enables building highly available, eventually consistent systems that can handle complex distributed scenarios.