How to Keep Order Data Consistent Across Multiple External Systems

Introduction

In modern software development, integrating with external systems (inventory, coupons, membership, finance, messaging, etc.) inevitably introduces network latency, system instability, and code‑design flaws that cause exceptions and data inconsistency. Manual fixes in production are painful and costly, so the article explores how to design the system up‑front to minimize inconsistency while keeping costs low.

Data‑Consistency Scenarios

The order‑placement process involves several systems and data objects:

Document system – business documents – main order flow (blocking)

Inventory system (external) – stock – consume inventory (blocking)

Coupon system (external) – coupon – redeem coupon (blocking)

Membership system (external) – member benefits – consume benefits (blocking)

Financial settlement system (external) – order settlement – initiate settlement (non‑blocking)

Message system – notification object – send SMS/email (non‑blocking)

Forward flow creates the order and simultaneously consumes inventory, coupons, membership benefits, and asynchronously triggers settlement and notification. The reverse flow handles business‑logic exceptions or external‑call failures by rolling back the local transaction, then using a scheduled task to revert inventory, coupons, and benefits, with retry logic if the rollback itself fails.

Design Guidelines for Consistency

The article proposes a lightweight final‑consistency architecture and lists concrete design points:

Apply proper front‑end debounce and back‑end distributed locks to prevent duplicate orders.

Allow users to retry from the UI when an order submission fails.

If using FeignClient for external calls, configure retries selectively; do not apply a blanket retry policy because not all external services are idempotent.

Agree on an idempotency key with external systems so repeated requests are recognized as the same operation.

When an external API only provides status queries and lacks idempotency, the caller must query first to decide whether to retry.

Analyze each external call to determine whether it blocks the main flow and whether strong data‑consistency is required.

Place external calls at the end of the business logic because remote calls are unstable.

For operations where consistency is critical but can be asynchronous (e.g., financial settlement), insert a task record and let a scheduler ensure eventual consistency.

For low‑consistency requirements (e.g., sending SMS), execute after the transaction commits using an asynchronous thread.

If a workflow involves multiple synchronous external calls, invoke the most error‑prone services first to reduce the need for later rollbacks.

When a synchronous external call fails, start a new transaction to persist compensation tasks for rolling back previously successful calls.

Use a scheduled timer to compensate for local‑transaction failures and restore consistency.

Appendix

Key reference diagrams (included as images) illustrate the core code logic, CAP theorem, BASE theory, classification of distributed transactions, and the half‑message mechanism for achieving final consistency.