Designing High‑Performance E‑Commerce Order Systems: Architecture & Core Functions

This article discusses the role of order systems in traditional e‑commerce enterprises, outlines the main functional modules and design ideas, and offers thoughts on the future development of order systems.

Role of Order System in Enterprises

Before building an enterprise order system, it is necessary to map the relationships among overall business systems and the upstream‑downstream links of the order system; only by clearly defining system boundaries can the responsibilities and functions of the order system be determined, ensuring efficient and simple collaboration among systems.

Relationship Between Order System and Business Systems

External Systems : All systems used by external users, including the public website, consumer‑facing apps, merchant back‑ends, and channel distribution platforms (e.g., bank credit‑card integration, WeChat partnerships). These are the front line of the business model.

Management Backend : Each front‑end business scenario has a corresponding backend module, such as the order system for transaction management, promotion system for discount management, product system for catalog management, and content system for displaying information.

Public Service Systems : As the enterprise matures, common functionalities are abstracted into platform services that provide foundational capabilities to other applications, improving architectural rationality and service efficiency.

Upstream and Downstream Relationships of Order System

The order system receives user information, converts it into product orders, and manages and tracks order data, serving as a crucial client‑facing link in the transaction flow. Downstream, it connects to product, promotion, warehouse, membership, payment, and other systems, acting as a bridge between the front and back ends of the e‑commerce platform.

Business Architecture of Order System

Order Service : Provides user‑facing services such as order list, order details, and online ordering, as well as multidimensional order data for public business modules.

Order Logic : Core module handling order creation, payment, production, confirmation, completion, cancellation, and related rules for order status, amount calculation, and inventory adjustments.

Underlying Services : Enterprises often modularize common services (e.g., product system, codebase, databases, APIs). However, order creation may require data scattered across many systems, leading to high latency and maintenance costs. Integrating required public service interfaces directly into the order system mitigates these issues.

Core Functions of Order System

Order Content Information

The order system stores real‑time data about products, discounts, users, and payments to enable efficient and precise management and interaction with downstream systems such as promotion, warehouse, and logistics.

以一个通用B2C商城的订单为例，梳理其包含的信息如下：

It is important to note that order types become multi‑dimensional as platforms grow, requiring distinct processes and states for each type to support classification and extensibility.

Process Engine

The process engine abstracts the end‑to‑end flow of an order—from creation to completion—into standardized rules. Different product or transaction types may have vastly different flows, so a dedicated engine helps manage these variations.

Each order flow includes forward processes (normal purchase) and reverse processes (modifications, cancellations, refunds, returns), triggered either automatically by the system or manually by users.

Forward Process

Example of a typical B2C order system : The flow can be abstracted into five steps—order creation, order payment, order production, order confirmation, and order completion.

1. Order Creation : After a user places an order, the system gathers product information, applicable discounts, and the user's membership benefits. Inventory deduction rules determine when stock is reduced—either at order placement or after payment.

Placement‑time inventory reduction : Advantages—friendly user experience, simple logic; Disadvantages—risk of malicious orders and stock loss; Solutions—order expiration, purchase limits, risk control.

Payment‑time inventory reduction : Advantages—reduces waste from invalid orders; Disadvantages—payment latency may cause overselling; Solutions—re‑verify inventory before payment, provide stock warnings.

Both methods have pros and cons; the choice depends on scenarios such as flash sales (use placement‑time reduction) versus high‑stock items with moderate traffic (use payment‑time reduction).

2. Order Payment : After payment, the system records payment details (transaction ID, timestamp). Depending on business models, orders may be split across channels or warehouses.

Order splitting occurs when items come from different channels (self‑operated vs. third‑party) or when SKUs require separate handling due to warehouse location, shipping constraints, etc.

3. Order Production : The order is sent to the warehouse for picking, packing, and dispatch.

4. Order Confirmation : After delivery is signed, the system prompts the user for feedback; confirmation does not imply transaction success but marks the start of after‑sales service.

5. Order Completion : Occurs a set number of days after receipt, ending the after‑sales support window.

Reverse Process

Reverse processes handle modifications, cancellations, refunds, and returns, each interacting with relevant downstream systems.

Order Modification : Allows updates to address or contact information after placement.

Order Cancellation : If the user cancels before payment, inventory and promotions are restored.

Refund : After payment, a refund request triggers a refund order, interacting with payment and promotion systems.

Return : A return request also restores inventory and processes refunds, requiring logic for discount allocation.

State Machine

A state machine manages order status logic through three elements: current state, action, and next state.

Current State : The present status of the order.

Action : An operation that may transition the order to a new state.

Next State : The state after the action is applied.

Designing the state machine must reflect real business scenarios, defining fine‑grained states for system, merchant, and buyer perspectives.

Enterprises may maintain multiple state machines to accommodate different order types and business models.

Evolution of Order System

As business volume and forms evolve, companies may operate multiple order systems for different scenarios, leading to fragmented order data, duplicated interfaces, and increased maintenance effort.

这种状况的出现，将会给平台带来非常大的发展瓶颈，如：

Three separate order systems handling different order types result in inconsistent order metrics, fragmented front‑end displays, and duplicated development effort across mobile and web channels.

Future architecture should split the order function into an Order Center (centralized order data management) and business‑specific order systems, providing unified services to all modules.

Conclusion

Building an enterprise order system should not aim for a one‑size‑fits‑all solution nor an overly minimal one; it must align with market conditions, company strategy, and specific business needs to define the optimal design and iteration plan.

Ultimately, the order system should evolve in harmony with overall company growth.