How Baidu’s Transaction Middle‑Platform Asset System Ensures Consistent, Secure User Funds

System Introduction

Baidu's transaction middle‑platform asset system, built on Baidu's payment and transaction infrastructure, consolidates and manages C‑end personal cash and virtual assets (e.g., virtual coins) within the company, providing a secure, reliable user‑asset management capability that complies with national clearing regulations.

Main Business Scenarios

The system currently serves over 20 business lines, including video rewards, Q&A, legal services, and Baijiahao virtual currency, supporting three core asset types: virtual coins, cash, and asset accounts.

Asset Business Flow

Cash‑type assets follow a typical flow: users recharge, tip, consume, and withdraw; the platform handles payment, refund, and settlement, supporting multiple withdrawal methods (Alipay, WeChat, Du Xiaoman, bank cards). The system also supports automatic or user‑initiated withdrawals.

System Detailed Breakdown

4.1 Asset Consistency Assurance

To guarantee data consistency, the system adopts two measures: payment consistency (full‑parameter signature verification) and change consistency (final consistency with data reconciliation). Hotspot accounts are distinguished from non‑hotspot accounts; the former use distributed cache with asynchronous batch synchronization to the database.

4.2 Double‑Entry Accounting

The system implements double‑entry bookkeeping: every debit has a corresponding credit, ensuring atomicity, idempotent interfaces, and traceable account changes. It defines multiple account types (reward cash, general reward, withdrawal debt, withdrawal) and outlines their inflow/outflow rules.

All debits must have matching credits (except recharge/withdrawal).

Each transaction updates the balance counter and inserts a detailed ledger entry.

A public fund pool is established for business platforms.

4.3 Hotspot Accounts

Hotspot accounts experience high concurrent balance changes. Real‑time accounting inserts only ledger details, marking them as un‑summarized; an asynchronous process aggregates these details to update the actual balance. Three balance views are maintained: ledger balance, actual balance (ledger + pending), and cache balance (real‑time view).

4.4 Storage Design

Due to high transaction volume, the system shards databases by user ID and business order, creating 16 shards with 1024 tables each. Hotspot accounts cause data skew; the system archives data older than three months to historical tables and uses Elasticsearch (via Canal binlog capture) for real‑time, multi‑dimensional queries.

4.5 Regulatory Compliance

Traditional B2C payment models cannot satisfy C2C scenarios due to lack of verification for both parties. The system adopts a personal ledger approach, registering individual user information with banks to meet national clearing and financial supervision requirements.

Conclusion

The asset system is designed to support all payment‑related scenarios across Baidu, addressing payment, clearing, settlement, and disbursement challenges. Ongoing iteration will further refine functionality, ensuring stable, rapid growth for the company’s diverse business lines.