How to Handle Hot Account Deduction in High‑Concurrency Systems

Background

In large‑scale systems, updating hot accounts is a typical high‑concurrency scenario. Architects must achieve low latency while maintaining data consistency.

Analysis

High concurrency brings two main problems:

Heavy traffic causing long response times or system overload. Solutions include traffic dispersion, smoothing, throttling, traffic control, system decomposition, caching, and asynchronous processing.

Data inconsistency. Solutions involve strong, weak, or eventual consistency via transactions, locks, message queues, and reconciliation.

Solution 1: Database Optimistic Lock

Suitable for moderate concurrency (≈100–1000 QPS). Use a version column and ensure the account balance does not become negative:

UPDATE account SET amount = amount - 100 WHERE version = 10 AND amount - 100 > 0;

Key points: add a version field and guard against negative balances.

Solution 2: Redis Deduction with Asynchronous Merge

When concurrency grows (< 5,000 QPS), pure optimistic locking may crash the DB. A simpler approach is to perform deductions in Redis and sync to the database asynchronously.

Deduction log: write logs to a file or a local DB table for higher write performance.

Redis deduction: decrement the account amount in Redis.

Asynchronous aggregation: schedule a task every 30 seconds–1 minute to sync Redis back to the DB, using optimistic or distributed locks to avoid conflicts.

Solution 3: Data Sharding with Asynchronous Merge

For massive traffic (10 k–100 k QPS), deeper redesign is required.

DB sharding: split the account table into N tables (e.g., 1–128), possibly across multiple databases.

Sharded caching: distribute data across multiple Redis instances or local caches for deduction.

Asynchronous aggregation: similar periodic sync as in Solution 2, with lock control.

Central scheduler: monitor each shard, route deductions to shards with sufficient balance, and coordinate using distributed locks.

Other Approach: MQ‑Driven Asynchronous Batch Deduction

Deduction request: write a Redis deduction request to a message queue.

Batch deduction: the consumer pulls records in batches, computes total amounts, and updates accounts in one operation.

Read‑Side Considerations

Read cache synchronized periodically with the DB.

Allow slight UI latency and provide a manual refresh button for users.

Conclusion

The article presents common solutions for high‑concurrency hot‑account deduction, allowing practitioners to combine methods based on their specific load and consistency requirements.