Mastering High-Concurrency Inventory Deduction for Flash Sale Systems

Introduction

This article addresses a real‑world high‑concurrency problem: reducing inventory safely during flash‑sale (秒杀) events.

With the rapid growth of online shopping, promotional activities generate massive order spikes, causing frequent reads and writes to popular product stock in the database. Simple read‑write locking can prevent overselling but does not scale under heavy load.

First Attempt

Initially, we consider data consistency and use database locks to avoid overselling, while also improving MySQL performance through hardware upgrades, optimistic locking, and SQL optimization. However, MySQL’s read‑write concurrency limits remain a bottleneck.

Introducing a cache layer (Redis) can offload read requests, improving interface performance, and synchronize the cache during stock deduction.

Pure lock‑based solutions cause all requests to wait for the lock, leading to timeouts and system collapse under high concurrency, and they also risk MySQL‑Redis data inconsistency.

Step‑by‑Step Optimization

We refactor the architecture by encapsulating inventory operations into a dedicated module that relies on Redis for both queries and deductions, updating MySQL asynchronously. This improves performance and concurrency.

Workflow:

However, this design still suffers from Redis single‑node performance limits and lacks horizontal scalability.

Scaling Up

To achieve horizontal scalability, we look at mature middleware such as Kafka and Elasticsearch, which use sharding. We apply a similar sharding concept to inventory by partitioning stock across multiple Redis instances.

1. Partition

Each partition is a Redis‑based stock shard storing a portion of the total inventory. Requests select a partition for deduction, reducing single‑node pressure and enabling horizontal scaling via Redis clusters.

To mitigate data skew, we adopt a dynamic inventory injection and sub‑domain isolation strategy.

Each partition contains two sub‑domains. The scheduler tracks the active sub‑domain; when its inventory falls below a threshold, it switches to the other sub‑domain and triggers a task to synchronize pre‑allocated stock.

This ensures limited inventory per sub‑domain, preventing skew.

The partition scheduler maintains a registry of partition keys, their remaining stock, and sub‑domain info, removes exhausted partitions, and selects partitions randomly or round‑robin while checking stock sufficiency.

2. Asynchronous Stock Updates

An asynchronous workflow reduces database pressure. A detail table records each partition’s deduction events with a sync status. Two MQ triggers fire:

When the number of detail records in a partition exceeds a threshold.

Periodically (default every second) to batch and send deduction details.

Both triggers are independent and ensure idempotency via sync status and detail IDs.

3. Pre‑Allocated Stock Management

Inventory is split into pre‑allocated stock and actual stock. Example: a product has 10,000 units; a partition pre‑allocates 400 units, then receives an MQ update of 30 units, followed by another pre‑allocation of 100 units. The actual stock equals pre‑allocated pool plus pre‑allocated stock.

When the pre‑allocation pool is empty, the partition is removed from the registry. MQ updates modify actual stock and adjust both pre‑allocated and deducted values transactionally.

Conclusion

By combining caching, asynchronous processing, and a partitioned, horizontally scalable design, we can handle high‑concurrency inventory deduction while preventing overselling and ensuring system stability. Practical implementation still requires careful handling of distributed concepts, sharding, and pre‑allocation logic.