How to Build a High‑Concurrency, Strong‑Consistency E‑Commerce Order System

Core Process Breakdown

To grasp the order system, first answer three questions: how does a normal order flow from placement to completion, how to handle cancellations or returns, and how order states can change. These correspond to the forward flow, reverse flow, and state transition rules.

Forward Flow

The forward flow is the complete fulfillment chain: user places order → payment → merchant ships → user receives → transaction succeeds.

1. Order Placement

When a user clicks “Submit Order”, the system performs invisible steps: product validation (checking availability and specifications), price calculation (base price + promotions – coupons – points), and inventory lock (pre‑deducting stock with a 15‑30 minute payment window).

The final order chain is: select product → confirm address/coupons → submit order (validation, price) → lock inventory → generate pending order.

2. Payment

Payment is the money‑goods clearing key. The flow includes three steps: the order service creates a payment record and returns a payment link/QR code; the third‑party payment channel notifies the system asynchronously; the system verifies the callback, updates the order to “Paid”, and finalizes inventory deduction.

After order creation, call the payment service to generate a payment order and return a link/QR code.

After user pays via WeChat/Alipay, the channel sends an asynchronous notification.

System receives the notification, verifies it, changes order status to “Paid”, and permanently deducts the locked inventory.

Typical problem: lost payment callbacks. Solution: active query + retry – the payment service polls unpaid orders every minute, retries up to 30 minutes to ensure no result is missed.

3. Fulfillment

After payment, the merchant fulfills the order. The core is status transparency – users see order progress, merchants track logistics, the platform ensures timeliness.

Key rule: real‑time status synchronization, especially for time‑sensitive goods.

Reverse Flow

Reverse flow handles cancellations and after‑sale scenarios, which are common. It consists of “Cancellation” and “After‑sale”.

Cancellation

Goal: release locked inventory and change status to “Cancelled”. Two scenarios: user‑initiated cancellation (only pending‑payment orders can be cancelled) and timeout‑based automatic cancellation (scheduled task releases inventory for orders exceeding the payment window).

After‑sale

After‑sale covers user‑initiated refund/return/exchange. Typical steps: user applies, merchant reviews (within 24 h) and provides return address, user ships back, merchant verifies, triggers refund via payment channel, and finally updates order status to “After‑sale Completed”. Consistency challenge: refund status may be inconsistent; solution is retry mechanisms, logging, and manual compensation.

Core Functional Implementations

Order creation is the most complex step, requiring millisecond‑level coordination across product, user, coupon, and inventory services. Key challenges and solutions:

Inventory competition & oversell : Use Redis atomic DECR for normal sales, fallback to DB row lock for failures; for flash‑sale, combine Redis pre‑deduction with a message‑queue “spike” buffer; for extreme peaks (e.g., Double 11), use Redisson distributed lock per product ID.

Duplicate order prevention : Front‑end disables the submit button for 3 s and sends a UUID; back‑end checks a Redis idempotency key; database enforces a unique composite index (user ID + product ID + timestamp) as a final safeguard.

Cross‑service data consistency : Adopt TCC (Try‑Confirm‑Cancel) pattern – each service performs a Try (e.g., pre‑lock inventory), if all Try succeed then Confirm (final lock), otherwise Cancel (rollback).

Order Query

High‑frequency queries require performance optimization: cache hot orders in Redis, shard databases by user ID, and route complex queries to read‑only replicas.

Order Cancellation

Beyond status change, it must accurately release locked inventory and unfreeze coupons. Use delayed messages (RocketMQ) with the order’s timeout and a periodic task to ensure no order remains stuck.

Order Status Synchronization

When order state changes, Kafka asynchronously notifies related systems (inventory, logistics, finance) to guarantee real‑time propagation and reliability (persistent messages, retry, dead‑letter queue).

Order Statistics

Real‑time stats use Flink on change logs (seconds‑level latency); offline stats use Spark daily batches for accurate reports.

System Architecture

The architecture is layered and decoupled: Access layer, Application layer, Data layer.

Access Layer

Provides traffic control: rate limiting (token bucket per interface), circuit breaking (e.g., payment service error rate >5% triggers fallback), and anti‑scraping (IP‑based request throttling).

Application Layer

Micro‑service architecture splits responsibilities: Order Service (core order logic), Payment Service (third‑party integration), Inventory Service (stock lock/release), Logistics Service (shipment tracking), User Service (profile & address). Communication uses synchronous RPC (Dubbo) for latency‑sensitive calls and asynchronous messaging (RocketMQ) for decoupled events.

Data Layer

Multiple storage solutions based on data characteristics:

MySQL : core order tables with transactions, sharded by user ID.

Redis : hot orders cache, distributed locks, idempotency keys.

RocketMQ : asynchronous events (order created, payment completed).

Elasticsearch : complex order search queries (time, amount, status).

Conclusion

A stable e‑commerce order system tightly intertwines process, functionality, and architecture. The forward chain must secure the “order‑pay‑fulfill” loop, the reverse chain must robustly handle cancellations and after‑sales, strict state transition rules prevent inconsistencies, and layered backend design with traffic control, micro‑services, and appropriate data stores ensures scalability, reliability, and real‑time performance.