Designing a Scalable, High‑Availability Order System: Architecture Insights

1. Order System Overview

1.1 Business Scope

Service lines include express, freight, small‑package, large‑package, cold‑chain, international, B2B contract logistics, CLPS, Jingxi, and three‑in‑three‑out processes (procurement in, return in, allocation in, sales out, return out, allocation out).

1.2 Order Center Value

1. Decoupling (enhanced system stability)

Original system: Transaction and production were tightly coupled; new business requirements impacted multiple upstream and downstream systems (ECLP, external orders, waybills, terminal systems), causing cross‑line dependencies.

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

Business lines are also decoupled: changes in a single line affect only its specific workflow, improving overall process stability.

2. Faster New Business Onboarding

The order center provides reusable standard capabilities to the front‑end, accelerating the integration of new services.

By splitting the monolithic original system into smaller composable applications and supporting on‑demand workflow orchestration, new businesses can quickly reuse central capabilities, avoiding duplicate development.

3. Unified Global Data Model

Original system: Orders were scattered across multiple systems (external orders, ECLP, large‑package), each with its own database and inconsistent semantics.

New system: The order center defines a standard order data model, consolidating data from different businesses into a single system, reducing redundant development, breaking departmental silos, and providing standardized data for group analysis and future innovation forecasting.

2. Architecture Introduction

2.1 Overall Architecture Design

The technical middle‑platform upgrade rebuilds the transaction system into a four‑layer architecture: access → transaction → fulfillment → execution.

The transaction order layer handles the contract between logistics and customers and distributes tasks to the downstream Order Fulfillment Layer (OFC).

2.2 Real‑Time Data Layer Architecture Design

2.2.1 System Interaction Diagram

The order center’s standard interfaces perform document aggregation at the upper layer, while the data layer also provides unified aggregation.

Business architecture is decoupled from data concerns; high‑availability and high‑performance designs such as distributed databases, caching, and consistency are separated from business logic.

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, consuming message queues to write order data into Elasticsearch, HBase, and MySQL.

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, solving pagination issues during data migration.

2.2.2 Technical Architecture Diagram

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

Distributed cache (Redis) for hot order data, with primary, standby, and temporary caches for resilience.

Message queue (JMQ) for asynchronous order processing, traffic shaping, and topic isolation per business scenario.

Complex queries handled by Elasticsearch, with Redis and HBase as secondary stores.

Low‑cost persistent storage using HBase columnar database for massive data.

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

Multi‑tenant architecture separates tenant data, enabling dynamic scaling and higher resource utilization.

2.3 Design Advantages

2.3.1 High Availability

Application servers, MySQL, Redis, HBase, JMQ deployed across multiple data centers; Elasticsearch in dual‑data‑center 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 Processing

Database sharding and table partitioning.

Hot‑cold data separation.

Columnar storage with HBase.

2.3.4 Data Security

Sensitive information is encrypted at rest; logs, Redis, Elasticsearch, MySQL, and HBase all follow the “who stores, who encrypts; who uses, who decrypts” principle.

3. Order Data Model

3.1 PDM Model

The order model is designed based on unified business attributes, abstract common models, and aggregated entities, covering main file info, product info, logistics service info, marketing info, financial info, customer channel info, shipping/receiving info, operation info, and extension info.

3.2 Model Extensibility

3.2.1 Standard Model Extensibility Design

With dozens to hundreds of identifier fields, adding new fields for each requirement would bloat the model. Instead, a key‑value approach stores identifiers within their respective business domains (order ID, product ID, marketing ID, etc.).

3.2.2 Personalized Business Model Extensibility

A configurable database field management solution allows orders to map business identity, type, and field to specific tables and columns. Each table reserves N extension attributes; the same attribute can represent different meanings for different business contexts, enabling flexible storage.

4. Future and Challenges

4.1 Personalized Query

Increasing demands for fuzzy search and real‑time aggregation pose challenges; consolidating all Elasticsearch indices in a single cluster can affect stability, while splitting them hinders cross‑business queries.

4.2 Unit‑Based Architecture

Current order persistence TP99 is 47 ms; without cross‑data‑center traffic it drops to 20 ms, showing the performance impact of cross‑region requests. Unit‑based deployment keeps a user’s requests within a single data center, eliminating cross‑region latency and allowing flexible geographic scaling.

4.3 Hardware Cost Control

Daily order volume and data size continuously grow, increasing hardware costs. Planned measures such as data archiving and hot‑cold‑warm tiered storage aim to reduce storage expenses.

-end-