How to Achieve Zero Over‑sell and Under‑sell with Redis Bucketed Inventory Deduction

Introduction

The article presents a solution for hot‑spot inventory deduction in high‑traffic order scenarios, designed by an inventory team to achieve strong consistency without over‑selling or under‑selling, while significantly improving deduction TPS and stability.

Background

Since the inventory team was formed, optimizing inventory deduction performance has been a continuous challenge. Collaboration with the database team led to kernel, application‑level, and architectural upgrades, markedly improving overall DB deduction performance. However, live‑streaming business growth introduced frequent hot‑spot deductions, making traditional DB‑only throttling insufficient.

Research on Existing Schemes

Conventional cache‑based solutions partition inventory into multiple Redis buckets and perform deductions directly in Redis, offering substantial performance gains. Their drawbacks include:

Inability to avoid under‑sell due to Redis failures (timeouts) where the application cannot determine success, leading to business loss.

Incapability of handling complex inventory models that require more than a single numeric field.

Full reliance on Redis stability; any Redis anomaly breaks the entire deduction flow.

These limitations prompted the need for a new approach that leverages Redis for speed but does not depend on it for correctness.

Merged Deduction Scheme

Key inventory concepts are introduced:

Sellable inventory (sq) : the actual quantity available for sale.

Pre‑deducted inventory (wq) : quantity reserved after an order is placed, moving from sq to wq.

Occupied inventory (oq) : quantity locked after payment, moving from wq to oq.

Inventory deduction details (snapshots) serve as immutable records, enabling idempotent distributed operations and tracking the lifecycle of deductions.

The overall workflow:

Reserve a portion of DB inventory (lock) and initialize the same amount in Redis for counting.

During order placement, deduct from Redis buckets; if successful, insert a deduction record into the DB. Failure falls back to the legacy DB‑only path.

One second after the order, a management module scans deduction records, aggregates the actual quantity to be deducted, and commits the merged change to the DB.

Module Designs

Lock Inventory Module

Locks inventory by moving a portion of the DB row’s sellable quantity (sq) to a lock field (lq) without decreasing sq directly; the DB update ensures sq‑lq‑δq > 0, preventing the lock from causing negative sellable stock. The locked amount is also seeded into Redis for fast counting.

Order Deduction Module

First deducts from the appropriate Redis bucket; on success, it writes a deduction detail to the DB. On failure, it reverts to the traditional DB‑only deduction flow.

Merge Commit Module

Invalidate the related Redis bucket to stop further deductions.

Scan all deduction details linked to the bucket, sum the quantities, and apply a single DB update.

Uses a covering index (invId, lockOrderId, quantity) to compute the sum efficiently; benchmark shows negligible DB impact.

Inventory Recovery Module

Releases pre‑locked inventory back to sellable stock in scenarios such as merchant edits setting total stock to zero or critical cases where Redis bucket stock is insufficient.

Anti Over‑sell/Under‑sell Design

DB update uses SET sq = sq - δq WHERE sq - lq - δq > 0 to prevent over‑sell.

Redis bucket counts never drop below zero, guaranteeing no over‑sell.

In high‑concurrency situations, a Redis barrier prevents missed scans from causing over‑sell.

Automatic Lock Module

Detects hot‑spot items via query patterns, pre‑locks inventory proactively, and continues automatic locking as orders proceed.

Performance Evaluation

Stress Test Results

In a single‑row hot‑spot test, non‑merged deduction peaked at ~14k TPS, while merged deduction reached ~32k TPS, more than doubling performance. Real‑world traffic is lower due to upstream rate limiting.

Online Results

With rate limiting enabled, peak TPS stayed around 7k+. Merged deduction achieved 100% success with ~7 ms latency, whereas non‑merged paths showed ~80% success and ~15 ms latency.

Conclusion

The article presents a complete, strongly consistent inventory deduction solution based on distributed caching, combining Redis counting with DB‑backed verification to eliminate over‑sell and under‑sell while delivering substantial performance gains.