Inventory Pre-Reservation: Challenges, Solutions, and Performance Optimizations

1. Inventory pre‑reservation overview: after a consumer places an order, the inventory system reserves stock for the order, reducing the available quantity. This core logistics process must be reliable to avoid stockouts or overselling.

2. Challenges and responses:

2.1 Performance challenges – high‑concurrency scenarios (e.g., flash sales) cause heavy database locking on hot items, limiting throughput to about 50 TPS.

Solutions investigated:

• Asynchronous rate limiting – slows down reservation requests to reduce hotspot pressure; simple with low implementation cost but requires asynchronous interaction with the ordering system.

• Horizontal stock splitting – divides a product’s stock across multiple tables or rows, turning one hot record into several cooler ones; improves throughput (e.g., 3 splits raise capacity from 50 TPS to over 100 TPS) but adds complexity and may cause “stock exists but cannot be reserved” cases.

• Cache‑based write‑traffic mitigation – uses Redis (or similar) to handle reservation operations, achieving up to 1,200 TPS, a 24× increase, with lower latency (TP99 reduced to 130 ms).

2.1.2 Solution comparison table:

Solution

Lossless support for business

Implementation cost

Asynchronous rate limiting

No, only works with async order interaction

Low

Horizontal stock splitting

No, may cause un‑reservable stock

Medium

Cache‑based write mitigation

Yes

High

Based on merchant size and risk, the article recommends asynchronous rate limiting for large key‑account merchants with async order flow, and cache‑based mitigation for others.

2.1.3 Performance results: hotspot reservation TPS rose from 50 to 1,200 (24×), and TP99 dropped from 3,000 ms to 130 ms.

2.2 Thread synchronization issues – multiple threads updating the same stock can cause data corruption. Solutions include MySQL row‑level locking within transactions and batch updates.

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);

Redis reservation uses Lua scripts to ensure atomicity.

2.3 Deadlock problems – arise from multiple orders locking overlapping items. Prevention via lock ordering (consistent lock acquisition sequence) is illustrated with pseudo‑code.

public Result handleOccupyRequest(List
paramList) {
    // Long comparator based on stock ID
    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);
    }
    // business logic
}

2.4 Data consistency between Redis and DB – ensures eventual consistency via DB‑locked stock plus Redis transactions, MQ retry mechanisms, and periodic consistency checks. Low‑stock items are checked after each change; high‑stock items are checked at defined intervals.

Overall, the article presents a comprehensive set of architectural and implementation techniques to scale inventory pre‑reservation, improve latency, avoid deadlocks, and maintain data integrity across heterogeneous storage layers.