Boosting Distributed Lock Throughput for Thousands of Orders per Second

Background

In many e‑commerce systems, inventory overselling occurs when multiple order services simultaneously read the same stock value and each deducts the quantity, leading to negative inventory. The article uses a scenario where two order service instances each try to purchase 10 iPhones from a stock of 12, resulting in one instance reducing the stock to -8.

Using a Distributed Lock to Prevent Overselling

A distributed lock ensures that only one client can hold the lock for a given key at a time. The locked client performs the whole order flow—checking stock, creating the order, and deducting inventory—before releasing the lock. This serializes access to the critical section, preventing multiple instances from deducting the same stock concurrently.

Limitations of Simple Distributed Lock in High‑Concurrency Scenarios

When thousands of requests target the same product, the lock forces all requests to be processed sequentially. Assuming each order takes about 20 ms, a single lock can handle only 50 orders per second for that product, far below the required throughput of thousands of orders per second.

High‑Concurrency Optimization Strategy

The key idea is to apply segment locking , similar to the sharding technique used in ConcurrentHashMap and LongAdder. Instead of a single lock for the whole inventory, split the total stock into multiple independent segments, each with its own lock.

For example, 1,000 iPhones can be divided into 20 segments of 50 units each (e.g., stock_01 … stock_20) stored either in separate database columns or separate Redis keys.

When an order arrives, a random segment is selected, the corresponding lock is acquired, and the order logic (check → deduct) is performed on that segment only. Up to 20 orders can be processed in parallel, effectively increasing throughput to 20 × 50 = 1,000 orders per second.

Implementation Considerations and Drawbacks

Data must be partitioned into multiple segment fields or keys, increasing schema complexity.

A random selection algorithm is required for each request to choose a segment.

If a chosen segment lacks sufficient stock, the lock must be released and another segment tried, adding extra logic.

These steps add development effort and operational overhead, but they can boost concurrency by dozens of times.

Further Improvements

The article notes that the inventory‑oversell scenario is only an illustration; other high‑traffic flash‑sale architectures may use different techniques such as queue‑based ordering, Redis atomic operations, or dedicated stock‑pre‑allocation services.