Boosting Inventory Reservation Performance: Strategies for High‑Concurrency Scenarios

1. Overview of Stock Pre‑Reservation

When a consumer places an order, the inventory system reserves the required stock for that order – a process called stock pre‑reservation. The system deducts the available quantity (e.g., from 5 to 4) and this step is critical for logistics; failures can cause out‑of‑stock sales or overselling.

2. Challenges and Solutions for Pre‑Reservation Capacity

High‑traffic events such as flash sales or live‑stream promotions generate many concurrent requests for the same hot items, creating a major technical challenge: how to safely decrement stock under high concurrency.

2.1 Performance Challenges

Concurrent threads locking the same product row in the database cause lock contention and severe performance degradation. Traditional database‑based reservation can handle only about 50 requests per second, far below the hundreds of requests per second observed in production.

2.1.1 Solution Exploration

Asynchronous Rate‑Limiting : Slow down reservation requests when possible, reducing hotspot pressure. Simple to implement with low risk, but requires asynchronous interaction with the order‑placement service.

Horizontal Stock Splitting : Partition a hot product’s stock into N separate tables or rows and route reservation requests based on a modulo of the request ID. This can raise capacity (e.g., three partitions raise throughput from 50 to >100 req/s) but adds complexity and may cause “stock exists but cannot be reserved” scenarios.

Cache‑Based Write Shielding (Redis) : Move the hot‑path stock decrement to Redis, which can sustain ~1,200 req/s for a hot SKU. This approach is transparent to upstream services but requires careful cache‑DB consistency handling.

2.1.2 Comparison and Selection

Solution

Loss‑less Business Support

Implementation Cost

Asynchronous Rate‑Limiting

No – only works when order service is async

Low

Horizontal Stock Splitting

No – may cause reservation failures

Medium

Cache‑Based Write Shielding

Yes

High

For large‑scale key accounts that already use asynchronous order flows, the async‑throttling approach is chosen; other merchants adopt the Redis‑based solution.

2.1.3 Performance Gains

Optimizations increased hot‑item reservation TPS from 50 to 1,200 (24×) and reduced TP99 latency from 3,000 ms to 130 ms (≈4.3% of the original).

2.2 Thread Synchronization Issues

Multiple threads operating on the same product stock can corrupt data. The DB‑based solution uses MySQL transactions and row‑level locks, updating stock with an atomic UPDATE statement and rolling back on negative balances.

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‑based reservation runs the decrement inside a Lua script, leveraging Redis’s single‑threaded execution to avoid race conditions.

2.3 Deadlock Problems

Deadlocks arise when multiple orders concurrently lock overlapping product rows, causing circular wait conditions. They can also occur across different processes (reservation, purchase, cancellation) that each lock different stock dimensions.

Deadlock Prevention

Enforce a consistent lock ordering across all transactions. Example pseudocode sorts stock IDs before acquiring locks:

public Result handleOccupyRequest(List<CalcOccupyRequest> paramList) {
    // sort stock IDs to keep lock order consistent
    Comparator<Long> comparator = Comparator.naturalOrder();
    if (saleableStockIds != null) {
        Collections.sort(saleableStockIds, comparator);
    }
    if (otherStockIds != null) {
        Collections.sort(otherStockIds, comparator);
    }
    // business logic follows
}

2.4 Data Consistency Between Redis and DB

Both Redis and the database maintain stock data, so eventual consistency must be guaranteed.

Initialize with a DB‑lock plus Redis transaction to keep both stores in sync.

Use MQ retries and a fallback task system for asynchronous reconciliation.

Introduce a “cache operation amount” counter: cache_stock + cache_delta = db_stock. The counter offsets the latency of DB updates.

Perform multiple consistency checks; a single successful check validates the data.

For low‑stock items, compare after every change; for abundant stock, compare at configurable intervals to reduce overhead.

These mechanisms together ensure high‑throughput, low‑latency inventory reservation while maintaining correctness across distributed components.