Design and Architecture of an E‑commerce Order System

The article introduces the essential role of an order system within a traditional e‑commerce enterprise, emphasizing that it must first clarify the boundaries of surrounding business systems to define its responsibilities and ensure efficient interaction.

It categorizes related systems into three layers: external systems (customer‑facing websites, merchant back‑ends, and channel integrations), management back‑ends (order, promotion, product, and content services), and common service systems that provide shared infrastructure for other applications.

Upstream, the order system receives user information and transforms it into product orders while tracking order data; downstream, it interfaces with product, promotion, inventory, membership, and payment systems, acting as a bridge between the front‑end and back‑end services.

The business architecture is divided into three main modules: the order service (user‑facing functions like order list, details, and placement), order logic (core workflow handling creation, payment, production, confirmation, completion, cancellation, refunds, and returns), and underlying services that aggregate data from various public modules to avoid scattered calls.

Core order content includes product, discount, user, and payment information, with a need for multi‑dimensional order classification to support diverse business scenarios.

A process engine abstracts the entire order lifecycle into a standardized flow, separating forward processes (creation → payment → production → confirmation → completion) and reverse processes (modification, cancellation, refund, return), each with specific rules and triggers.

The article compares two inventory deduction strategies—order‑time deduction and payment‑time deduction—detailing their advantages, disadvantages, and mitigation measures such as order expiration, purchase limits, and risk control.

It also outlines order splitting scenarios based on multiple sales channels or SKU‑level constraints, and describes subsequent stages like order production, confirmation, and completion.

A state machine governs order status transitions, defining current state, action, and next state, and highlights the need for fine‑grained status mapping across system, merchant, and buyer perspectives.

Finally, the article discusses the evolution of order systems, noting challenges of multiple parallel order systems and advocating a unified order center architecture to provide consistent services across business units.