Design and Architecture of Baidu Transaction Middleware Order System

In this article, a senior architect introduces Baidu's transaction middle‑platform order system, which underpins various Baidu products (Mini‑programs, Maps, Baijiahao, etc.) and supports both payment‑centric and full‑e‑commerce scenarios.

1. Required capabilities – The order system must handle user‑side actions (payment, order tracking, refunds), merchant‑side management (order status, split orders, after‑sale), and platform‑level functions (commission, risk control, anti‑fraud).

2. Service models – Three integration types are described: General (business maintains its own product and inventory, order system provides payment, marketing, refund, etc.), Self‑operated (order system offers full e‑commerce features including product, inventory, logistics), and Direct‑connect (business handles payment directly and order system only processes promotion and settlement).

3. Order lifecycle – The order progresses through creation, payment, fulfillment, success, cancellation, and refund, forming a finite state machine with forward (purchase) and reverse (after‑sale) flows.

4. Architectural evolution – Initially a monolithic system handling simple payment and refund for small‑scale services. As business expanded, requirements grew to include logistics, multi‑entry payments, live‑streaming, auctions, and regulatory compliance, prompting a shift to a distributed architecture.

4.1 Instruction orchestration – The system abstracts business processes into independent instructions (e.g., payment, user, split‑order) that can be composed like building blocks, enabling flexible templates for different scenarios and improving extensibility.

4.2 Performance optimizations

Caching frequently accessed, rarely changed data (LRU cache) to shorten call chains.

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

ThreadLocal for intra‑thread data sharing; TransmittableThreadLocal for propagating context across async threads.

Database scaling: vertical isolation of business domains, horizontal sharding of large tables (order, refund, CPS), and use of sharding keys based on user ID to keep related data in the same shard, enabling transactions.

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

Figures illustrating the architecture, instruction flow, and sharding strategy are included throughout the article.

5. Summary – Building a reliable order system requires aligning technical design with business needs, reducing complexity where possible, leveraging open‑source components, and balancing performance, scalability, and cost.