How Baidu’s “My Wallet” Unified User Assets with Scalable Backend Architecture

Background

Baidu App serves over 200 million daily active users, generating diverse asset information (cash, activity, virtual assets) across many business lines. Users needed a unified view of all asset data to improve asset awareness and user experience.

Business Overview

The “My Wallet” feature in the personal center aggregates user asset information into a single entry point with four configurable quick‑access slots. These slots expose balances, activity cashbacks, coupons, virtual currencies and other links, allowing users to view and manage assets across Baidu’s ecosystem.

System Architecture

The wallet serves three primary audiences: end‑users, business‑side integrators, and operations staff. Front‑end entry points are built with the Talos framework. User requests first check a Redis presence flag; if cached, data is returned directly. Otherwise, the service routes requests based on configuration rules, aggregates data from multiple sources, and falls back to cached data when downstream services fail.

Technical Details

Asset Data Synchronization

Asset data is scattered across independent business lines, making direct API exposure difficult due to high QPS, latency, and stability requirements, especially during peak events. The wallet defines three integration principles:

Business lines displayed in the personal center must sync assets to the wallet with built‑in availability and degradation strategies.

Home‑page displayed data may either sync to the wallet or provide a high‑performance API for on‑demand queries.

Secondary and tertiary pages require either a query API or a landing page for real‑time detail retrieval.

Data Sync Mechanism

Only the latest asset snapshot is stored; historical snapshots are omitted to reduce storage. Business lines push change notifications, which the wallet enqueues into a message queue. Workers consume these messages, pull the latest data from the source, and update the wallet store. This decouples burst traffic from upstream services, enables retry logic and flow control, and batches updates per user to limit downstream load.

Real‑time Query

For business lines that do not push data, the wallet provides a real‑time query API (balance and paginated detail). Balance responses are cached in Redis for fallback during downstream failures. Detail queries are split into pagination and monthly summary interfaces; the wallet aggregates data locally when possible and reduces the number of summary calls by analyzing month distribution in the paginated results.

Multi‑level Caching

Given billions of user IDs and expected QPS in the tens of thousands, the wallet uses a two‑layer cache. The first layer stores a presence flag in Redis to filter out users without assets. The second layer caches actual asset data. After evaluating HyperLogLog, Bloom filters, and RoaringBitmap, a sharded RoaringBitmap solution was chosen, achieving ~500 MiB storage for 10 billion IDs with a 2.14 % false‑positive rate.

Read‑Write Separation

Read‑heavy traffic (user page loads) and write‑heavy traffic (data pulls, authorization updates, queue consumption) are isolated into separate services. Reads serve cached data to users, while writes handle upstream pulls, configuration updates, and message‑queue consumption. RPC links coordinate between the services, ensuring that failures in one direction do not impact the other.

Data Consistency

When asset changes occur, business lines push updates to the wallet; on user entry, the wallet also pulls the latest data to reconcile any missed pushes. A nightly T+1 reconciliation job compares Redis and MySQL records, pulling missing updates to ensure eventual consistency.

Configurability

The wallet adopts a configuration‑driven design. Integration configuration (API endpoints, sync modes) and display configuration (names, links, icons, amounts) are stored in Redis. Versioned releases with whitelist rollout mitigate risk during updates. All configuration is mirrored to Baidu Cloud Control (GCP) to serve as a fallback when Redis is unavailable.

Database Design

To handle massive user volume, the wallet shards MySQL tables by user ID (sharding key). This enables horizontal scaling, maintains transactional integrity per user, and simplifies future capacity expansion.

Conclusion

The “My Wallet” project demonstrates how Baidu unified disparate asset data across its app ecosystem through a scalable backend architecture that emphasizes high availability, low latency, and operational flexibility. Ongoing work focuses on expanding business‑line integrations, further stabilizing the platform, and continuously enhancing the user experience.