Handling Hotspot Accounts in Baidu Waimai Financial Accounting System: Challenges and Solutions

Abstract: After upgrading the settlement system to version 2.0 and building a balance‑based financial accounting system, this article discusses the phenomenon of high‑frequency “hotspot” accounts, analyzes the associated problems, and compares several solution approaches for various business contexts.

1. What is a hotspot account? A hotspot account is one whose transaction volume dominates the overall system or experiences frequent balance changes within a short period. Typical hotspot accounts are financial accounts that generate a large share of transaction flow.

2. Why hotspot accounts are difficult: Each balance change requires reading the current balance, recording a transaction, and updating the balance. High‑frequency concurrent updates on the same account lead to lock contention, drastically reducing system throughput.

3. Basic operation steps:

Obtain the current account balance.

Record the transaction flow.

Update the account balance with the change value.

Note: Certain operations (e.g., withdrawals) must verify that the balance does not become negative, so the first step cannot be omitted.

4. Example SQL using optimistic lock (repeatable read isolation):

start transaction;
select amount, version from account where account_id = A; -- returns AM, V
insert into trade(trade_id, account_id, income_amount, account_amount) values (xxx, A, 10, AM+10);
update account set amount = AM+10, version = V+1 where account_id = A and version = V; -- check affected rows
commit;

5. Solution research:

5.1 Asynchronous / delayed posting: Business operations only create transaction records and enqueue them. An offline script processes the queue in batches, calculates balances, and updates them. This eliminates lock contention and improves concurrency, but cannot handle operations that require immediate balance validation (e.g., withdrawals) and introduces processing latency.

5.2 Account splitting:

5.2.1 Separate credit and debit accounts: Credit operations use asynchronous or multiple credit accounts; a periodic job syncs credit flows to a dedicated debit account that handles withdrawals. Improves write concurrency, but adds system complexity and withdrawal delay.

5.2.2 Multiple sub‑accounts: The total account is divided into many sub‑accounts; each sub‑account handles a portion of credit/debit operations. Concurrency scales with the number of sub‑accounts, while withdrawal performance degrades as sub‑account count grows.

6. Choosing the best solution for different business accounts:

Rider accounts: low concurrency, require real‑time withdrawal – suitable for the simple optimistic‑lock approach (Solution 1).

Financial & settlement large accounts: high concurrency, no withdrawals – best served by asynchronous processing or account splitting (Solution 2).

Merchant and agency accounts: moderate to high concurrency with occasional withdrawals – can use Solution 2, or consider splitting approaches if manual withdrawals become necessary.

The article concludes that technical solutions must be matched to specific business requirements rather than pursuing a one‑size‑fits‑all architecture.