Order System Architecture Overview and Design

1. Order System Overview

1.1 Business Scope The service lines include express, freight, small‑package, large‑package, cold‑chain, international, B2B contract logistics, CLPS, Jingxi, and three‑in‑three‑out processes such as procurement, returns, allocation, sales, and supply.

1.2 Order Center Value

1. Decoupling (Improving System Stability)

Original System: Transaction and production are tightly coupled; new business requirements affect multiple upstream and downstream systems (ECLP, external orders, waybills, terminal systems), causing cross‑line impact.

New System: Transaction and production operations are decoupled; transaction‑related needs are solved within the order domain, while production‑related needs are handled in the production domain, reducing mutual impact.

Business line decoupling allows each line to iterate independently, enhancing overall process stability.

2. Accelerating New Business Integration The order center provides reusable standard capabilities to front‑end services, enabling rapid onboarding of new business without duplicate development.

3. Providing a Unified Global Data Model

Original System: Orders are split across multiple systems and databases with inconsistent semantics.

New System: A unified order data model consolidates data, reduces redundant development, supports group‑level analysis and forecasting, and provides standardized order data.

2. Architecture Introduction

2.1 Overall Architecture Design

The system is rebuilt into a four‑layer architecture: access, transaction, fulfillment, and execution. The transaction order handles the contract between logistics and customers and distributes tasks to the downstream fulfillment layer.

2.2 Real‑Time Data Layer Architecture Design

2.2.1 System Interaction Diagram

System interaction is as follows:

The order center provides standardized interfaces that aggregate documents at the upper layer and also unify data collection at the data layer.

Business architecture is decoupled from data, with distributed databases, caches, and high‑availability designs handling consistency and performance.

Persistence System: Supports order creation, modification, cancellation, and deletion.

Search System: Provides order detail, list, status flow queries, and identification of Baichuan orders.

Relay System: Acts as a data hub, writing order data to Elasticsearch, HBase, and MySQL via message queues.

Data Reconciliation System: Ensures consistency across multiple storage middlewares.

Data Synchronization System: Syncs query conditions and display fields from the legacy system to the order center to resolve pagination issues during migration.

2.2.2 Technical Architecture Diagram

Read‑Write Separation (CQRS) to improve query performance and scalability.

Distributed Redis cache for hot order data, with primary, backup, and temporary caches for resilience.

JMQ message queue for asynchronous order processing, traffic shaping, and topic isolation.

Elasticsearch for complex order queries, combined with Redis and HBase for detailed retrieval.

HBase column‑family storage for low‑cost, massive data persistence.

Data consistency via strong transactions, eventual consistency, idempotency, compensation, distributed locks, and versioning.

Multi‑tenant architecture isolates tenant data and enables horizontal scaling and resource sharing.

2.3 Design Advantages

2.3.1 High Availability

Application servers, MySQL, Redis, HBase, JMQ are deployed across data centers; Elasticsearch runs a dual‑site master‑slave cluster.

Isolation, rate limiting, circuit breaking, traffic shaping, and monitoring.

2.3.2 High Performance

High‑performance caching.

Asynchronous processing.

2.3.3 Massive Data Handling

Database sharding and partitioning.

Cold‑hot data separation.

Columnar storage with HBase.

2.3.4 Data Security

Sensitive information is encrypted at rest; Log, Redis, ES, MySQL, HBase all follow "encrypt when storing, decrypt when using" principles.

3. Order Data Model

3.1 PDM Model

The order model is divided into main file information, product information, logistics service information, marketing information, financial information, customer channel information, shipping/receiving information, operation information, and extension information.

3.2 Model Extensibility

3.2.1 Standard Model Extensibility Design

With dozens to hundreds of identifier fields, adding new fields for each change would bloat the model; therefore a key‑value approach is used, grouping identifiers by business domain (order ID, product ID, marketing ID, etc.).

3.2.2 Personalized Business Model Extensibility

A configurable database field management scheme allows orders to map business identity, type, and field to specific tables and columns, reserving N extension attributes per table and interpreting them differently based on context.

4. Future and Challenges

4.1 Personalized Query

Increasing personalized query demands (fuzzy search, real‑time aggregation) can strain a single Elasticsearch cluster; splitting indices improves stability but hampers cross‑business queries.

4.2 Unit‑Based Architecture

Current order persistence TP99 is 47 ms (20 ms without cross‑data‑center). Unit‑based deployment keeps a user's requests within a single data center, eliminating cross‑center latency and allowing flexible regional expansion.

4.3 Hardware Cost Control

Rising daily order volume increases data size and hardware costs; strategies such as data archiving and hot‑cold‑warm tiering are planned to reduce storage expenses.

END