Design and Implementation of Baidu App Personal Wallet: Architecture, Data Synchronization, Caching, and High Availability

1. Background

Baidu App serves over 200 million daily active users and stores various asset types (cash, activity, virtual) across multiple business lines, making it difficult for users to locate and understand their total assets. A unified wallet was needed to aggregate, display, and provide a single entry for asset review.

2. Business Introduction

The "My Wallet" feature in the personal center gathers all user assets, offers unified management and display, and exposes four configurable shortcut slots for quick access to business functions and asset information.

3. System Business Architecture

The wallet serves three main parties: C‑end users, business integrators, and operations staff. Users access the wallet via a primary entry in the personal center or the wallet homepage, which is built with the Talos front‑end framework. Data is cached per user; if the cache indicates asset presence, the cached data is returned. Routing adapters select appropriate data rules for each module, and fallback mechanisms provide cached data when downstream services fail.

Technical Details

1. Asset Data Synchronization

Because asset data is scattered across heterogeneous business lines, direct API exposure would impose high QPS and stability requirements on each service. The wallet therefore defines synchronization principles: mandatory sync for exposed business slots, optional sync for homepage data, and real‑time queries for secondary pages.

1.1 Synchronization Process

When a business updates asset data, it notifies the wallet, which enqueues a message. The wallet server consumes the message, pulls the latest data from the business, and updates its storage. Batch processing and retry logic reduce load and handle failures.

1.2 Real‑time Query

For businesses that do not push data, the wallet defines query APIs. Balance queries are cached in Redis for fallback, while detail queries are split into pagination and monthly‑summary calls; the wallet aggregates results to minimize downstream requests.

2. Multi‑level Cache

Given billions of user IDs and peak QPS potentially exceeding 100 k, the wallet uses a two‑layer cache: the first layer quickly determines whether a user has any assets (implemented with a roaring bitmap shard), and the second layer stores the actual asset data. Redis holds the first‑layer cache, with DB as a fallback.

3. Read‑Write Separation

Read traffic (user requests) and write traffic (data pulls, message consumption) are handled by separate services communicating via RPC, ensuring that read‑side failures do not affect write operations and vice‑versa.

4. Data Consistency

A push‑pull hybrid model guarantees consistency: businesses push updates when assets change, and the wallet pulls the latest data when a user enters the personal center. Daily reconciliation jobs compare Redis and DB, pulling missing updates to achieve T+1 consistency.

5. Configuration Management

The wallet adopts a configuration‑driven approach for both integration and presentation. Base configurations are stored in Redis, with versioning, white‑list rollout, and fallback to GCP Config when Redis is unavailable.

6. Database Design

To handle massive user volume, the wallet shards data by user ID across multiple MySQL instances, enabling horizontal scaling while preserving transactional integrity within a shard.

5. Summary

The article presents the complete technical solution for building Baidu App’s personal wallet, highlighting challenges such as high availability, scalability, and rapid business integration. By simplifying architecture, employing multi‑level caching, read‑write separation, and robust configuration, the system delivers a seamless user experience while supporting continuous iteration and reliability improvements.