Three Redis Inventory Decrement Lock Patterns Explained

Redis inventory decrement locking patterns

1. Exclusive lock

Core idea – a single global lock protects the whole stock stored in one key.

Redis keys – stock (numeric counter) and lock:stock (lock flag).

Typical scenarios – very high consistency requirements, simple data model, low request concurrency, and when minimal operational complexity is desired.

Drawbacks – all requests are serialized, creating a performance bottleneck under high concurrency and preventing the use of Redis cluster parallelism.

2. Segmented lock

Core idea – split the total inventory into N independent segments, each with its own lock.

Redis keys – stock keys stock_a, stock_b, stock_c, … (total equals overall stock) and lock keys lock:stock_a, lock:stock_b, lock:stock_c, ….

Typical scenarios – hot‑spot items with high concurrency; the segmentation distributes lock contention across multiple keys, significantly improving throughput.

Drawbacks – possible fragmentation (a segment may be empty while others still have stock), requiring secondary routing or stock‑merge logic; increased management complexity.

3. Lock‑free / key‑quantization

Core idea – represent each unit of inventory as an individual Redis key (or as an element in a list/set). The existence of a key equals one unit of stock.

Redis keys – individual keys such as stock_1, stock_2, … stock_100, or a list stock_list containing items.

Atomic operation – decrement is performed by deleting a key ( DEL) or popping an element ( POP), which is atomic in Redis.

Typical scenarios – extreme performance needs (e.g., flash‑sale “seckill”) where lock overhead must be eliminated and first‑come‑first‑served fairness is required.

Drawbacks – high memory consumption due to a large number of keys, complex batch‑decrement logic, and slower initialization because many keys must be pre‑created.

Lua script atomic decrement

A Lua script can atomically check the stock and decrement it in a single Redis execution:

if (redis.call('get', 'stock') > 0) then
    return redis.call('decr', 'stock')
else
    return -1
end

The script avoids a network round‑trip for lock acquisition, making it faster than the exclusive‑lock approach while using less memory than the lock‑free design.

Asynchronous queue / buffer decrement

Requests are first written to a Redis List or Stream (acting as a queue).

A consumer later processes the queue and updates the persistent database.

This provides eventual consistency: the stock may not be reduced immediately, but the system remains highly responsive.

Local pre‑deduction

The application server fetches a batch of stock (e.g., 100 units) from Redis and caches it in local memory.

Subsequent user requests consume the local copy without contacting Redis.

A background reconciliation process synchronizes the local counts with Redis.

Each pattern offers a distinct trade‑off: exclusive lock guarantees correctness with low throughput; segmented lock balances concurrency and complexity; lock‑free maximizes speed at the cost of memory; Lua scripting provides a middle ground with atomicity and lower latency; asynchronous queuing favors responsiveness with eventual consistency; and local pre‑deduction reduces Redis latency at the expense of additional reconciliation logic.