Design and Architecture of Baidu Transaction Middle Platform Order System

The article introduces Baidu's transaction middle platform, a foundational infrastructure for the group's mobile ecosystem that supports cash register transactions and settlement scenarios. It serves multiple Baidu products such as Mini Programs, Map Taxi, Baijiahao, Zhaocaimao, and Haokan Video.

1. Capabilities of the Order System

The order system connects users, merchants, products, inventory, and after‑sale services, acting as the core driver of the entire transaction flow. Its capabilities are examined from three perspectives:

User view: payment pricing, order placement, logistics tracking, refunds, order search, etc.

Merchant view: order status management, order splitting, after‑sale handling, etc.

Platform view: order splitting, CPS commission, risk control, anti‑fraud, etc.

2. Service Models of the Transaction Middle Platform

The platform abstracts business into three integration types:

General type: businesses maintain their own product and inventory data and call the order system for aggregated payment. Functions include marketing, refunds, password‑free payment, promotion, settlement, reconciliation, risk control, etc. Example businesses: Baidu Maps, Baidu Medical, Xiaodu Mall.

Self‑operated type: the order system provides a complete e‑commerce capability (product, inventory, marketing, refunds, after‑sale, search, logistics). Example businesses: Zhaocaimao, Kuakuadou.

Direct‑connect type: businesses handle payment through their own channels and sync order data to the order system afterward, which then calculates promotion information for revenue sharing. Example businesses: Dangdang, Amazon.

3. Order Lifecycle and Process

The order lifecycle follows a finite‑state machine covering order confirmation, payment, shipment, success, cancellation, and refund. Two main flows exist:

Forward (payment) flow: user initiates purchase, selects payment channel (WeChat, Alipay, etc.), completes payment, triggers notifications, inventory and marketing deductions, and proceeds to merchant shipment or virtual delivery.

Reverse (refund) flow: after‑sale or refund requests are processed, involving merchant review, possible logistics for returned goods, and final refund to the user.

4. Architectural Overview

Initially, the system was a monolithic architecture handling simple payment and refund functions for a small user base. As business expanded to include logistics, diverse payment channels, live‑stream commerce, auctions, coupons, and regulatory requirements, the monolith faced scalability and performance limits.

To address these challenges, the architecture was refactored into a distributed, cloud‑native design using internal distributed databases, caching, and containerized deployment. Key architectural concepts include:

Command orchestration: business processes are broken into independent commands (e.g., payment command, user command). Commands are combined via templates to support various scenarios, following the open‑closed principle.

Order splitting command: after payment, the system may split an order for commission distribution (e.g., multi‑merchant e‑commerce) or for Q&A‑type services where the final service provider is determined later.

4.1 Command Orchestration Architecture

Commands act as modular operation units that can be assembled like building blocks. Templates define specific business flows, and the system instantiates them per request. This enables rapid support for new business scenarios and improves throughput, extensibility, and stability.

4.2 Performance Optimizations

Challenges identified include long serial execution chains and repeated database queries per command. Optimizations applied:

Caching of infrequently changing data (e.g., user and product info) with LRU eviction.

Asynchronous or degraded execution for non‑critical commands using thread pools.

Thread‑local data propagation to avoid redundant DB hits, enhanced with TransmittableThreadLocal for async tasks.

Database sharding (vertical and horizontal) to isolate order‑related tables, using a sharding key derived from user ID and order ID, ensuring queries can locate the correct shard efficiently.

Additional indexing and external search (e.g., Elasticsearch) for low‑latency queries beyond user ID/order ID.

These measures enable the order system to handle high traffic (e.g., 20,000 QPS) while maintaining low latency and consistency.

5. Summary

The article demonstrates how a reliable, extensible order system can be built by aligning technology choices with business needs, employing command orchestration, distributed architecture, caching, and database sharding. It also emphasizes pragmatic trade‑offs between feature completeness and architectural simplicity, and the importance of leveraging open‑source and third‑party services.