Building Inventory Pre‑Reservation Capability: Challenges and Solutions

After a consumer places an order, the inventory system reserves the required stock, a process known as inventory pre‑reservation. This operation reduces the available stock count and is critical to preventing overselling; any failure can block sales or cause stock inconsistencies.

Performance challenges arise when many orders target the same hot‑selling items simultaneously, leading to high lock contention in the database. Traditional DB‑based pre‑reservation can handle only about 50 TPS, far below the hundreds of TPS observed in peak scenarios.

Solution research explored three main approaches:

Async throttling – slowing down reservation requests to reduce hotspot pressure.

Horizontal stock splitting – dividing a product’s stock into multiple tables or rows and routing requests based on a hash of the order ID.

Cache‑assisted writes – using Redis as a fast front‑end for stock deduction, dramatically increasing throughput.

A comparison table shows that async throttling has low implementation cost but requires asynchronous interaction with the ordering system; horizontal splitting has medium cost and may cause partial failures; cache‑assisted writes have high cost but fully support business without loss.

After applying the chosen strategies (async throttling for large‑scale key accounts and cache‑assisted writes for the rest), the system achieved a 24× increase in TPS, raising the peak from 50 TPS to over 1 200 TPS and reducing the 99th‑percentile latency from 3 s to 130 ms.

Thread‑synchronization problem is addressed by using MySQL row‑level locks within a transaction to safely decrement stock. An example SQL batch update is:

UPDATE stock
    SET stock_num = stock_num + CASE id
        WHEN 1 THEN 'value1'
        WHEN 2 THEN 'value2'
        WHEN 3 THEN 'value3'
    END
WHERE id IN (1,2,3)

For Redis, the deduction logic is encapsulated in a Lua script executed atomically, preventing concurrent interference.

Deadlock mitigation relies on lock ordering: all involved stock IDs are sorted before acquiring locks. Sample Java code demonstrates the sorting step:

public Result handleOccupyRequest(List
paramList) {
    // Business logic
    Comparator
comparator = new Comparator
() {
        @Override
        public int compare(Long o1, Long o2) {
            return o1.compareTo(o2);
        }
    };
    if (saleableStockIds != null) {
        Collections.sort(saleableStockIds, comparator);
    }
    if (otherStockIds != null) {
        Collections.sort(otherStockIds, comparator);
    }
    // Further business logic
}

Data‑consistency between Redis and DB is ensured through an initialization flow that locks DB stock while performing a Redis transaction, and a synchronization flow that uses MQ retries and a fallback task system. Consistency checks compare "cache stock + cache operation delta" against the DB stock, with multiple verification rounds to tolerate transient delays.

Images throughout the original article illustrate the architecture, performance graphs, and flowcharts for initialization, synchronization, and cache processing.