Design and Evolution of an E‑commerce Order System

Overview

This article explains the role of an order system in a traditional e‑commerce company, outlines the design ideas of its main functional modules, and offers thoughts on the future development of order systems.

1. Role of the Order System in the Enterprise

Before building an order system, it is necessary to clarify the relationships among all business systems and the upstream‑downstream boundaries of the order system. Only by defining clear system boundaries can the responsibilities and functions of the order system be determined, ensuring efficient and concise collaboration between systems.

2. Relationship Between the Order System and Other Business Systems

(1) External Systems: All systems used by external users, including the public website, consumer‑facing apps, merchant back‑ends, and channel integrations (e.g., bank credit‑card cooperation, WeChat cooperation). These systems are the front line that connects the company with its commercial model.

(2) Management Middle‑Back Office: Each C‑end business scenario has a corresponding module, such as the order service for transaction management, promotion system for discounts, product system for product data, and content system for displaying information.

(3) Public Service Systems: As the enterprise matures, common functions are abstracted into platform services (e.g., authentication, logging) to improve architectural rationality and service efficiency.

3. Upstream and Downstream Relationships of the Order System

The order system receives user information, transforms it into product orders, manages and tracks order data, and serves as the crucial customer‑facing link of the transaction line. Downstream, it connects to product, promotion, warehouse, membership, and payment systems, acting as a bridge between front‑end and back‑end services.

4. Business Architecture of the Order System

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

(2) Order Logic : Core of the system, handling order creation, payment, production, confirmation, completion, cancellation, complex status rules, amount calculations, and inventory adjustments.

(3) Underlying Services : As enterprises grow, common services are modularized (e.g., product, code, database, APIs). However, order creation may need data scattered across many modules, leading to high coupling and maintenance cost. Therefore, the order system integrates required public service interfaces to reduce coupling.

5. Core Functions of the Order System

5.1 Order Content

The order stores real‑time data about products, discounts, users, and payments, enabling interaction with downstream systems such as promotion, warehouse, and logistics.

5.2 Process Engine

The process engine abstracts the entire order lifecycle from creation to completion, supporting both forward (order creation → payment → production → confirmation → completion) and reverse processes (modification, cancellation, refund, return). Each step may be triggered by system or manual actions.

Forward process example: order creation, payment, production, confirmation, completion. Reverse process includes order modification, cancellation, refund, and return.

5.3 Inventory Deduction Strategies

Order‑time deduction reduces inventory when the order is placed. Advantages: friendly user experience, simple logic. Disadvantages: vulnerable to malicious orders and stock‑out for genuine users.

Payment‑time deduction reduces inventory after payment confirmation. Advantages: avoids wasteful inventory consumption. Disadvantages: payment latency may cause overselling.

Solutions include setting order expiration, purchase limits, and risk control mechanisms.

5.4 Order Payment and Splitting

After payment, the system records payment details and may split orders based on different channels or SKU attributes (different warehouses, shipping requirements, weight/volume limits).

5.5 Order Production, Confirmation, and Completion

Production involves sending order data to the warehouse for picking, packing, and dispatch. Confirmation notifies the user after receipt, marking the start of after‑sales service. Completion occurs after a defined period post‑receipt, ending the order lifecycle.

5.6 Reverse Processes

Reverse processes cover order modification, cancellation, refund, and return. Each requires coordination with payment, promotion, and inventory systems to ensure data consistency.

5.7 State Machine

The state machine manages order status using three elements: current state, action, and next state. It enables fine‑grained status tracking for system, merchant, and buyer perspectives, and supports multiple state machines for different order types.

6. Evolution of the Order System

As business volume and forms evolve, enterprises may end up with multiple parallel order systems, leading to fragmented order data, duplicated development effort, and inconsistent user experience across web and mobile channels.

Future architecture should separate an Order Center (centralized order data management) from Business Order Systems (specific domain logic), providing unified services to all downstream modules.

Unified order center mitigates issues such as inconsistent order status, duplicated interfaces, and high maintenance cost.

Conclusion

Building an enterprise order system does not require a “big‑and‑all” approach nor a “small‑and‑precise” one; it must be tailored to market, company, and business realities, aligning with overall development strategy.

Ultimately, the order system should coordinate with the company’s growth, providing a solid foundation for future expansion.

牛逼啊！接私活必备的 N 个开源项目！