Key Techniques for Inventory Deduction in High‑Concurrency E‑commerce Systems

As online shopping becomes ubiquitous in China, platforms such as Taobao, JD.com, and Pinduoduo face intense inventory deduction challenges during high‑traffic events like Double‑11. When many users purchase the same SKU simultaneously, the inventory value must be decremented in a strictly serial order to avoid overselling, requiring locking mechanisms.

Key technical points of inventory deduction:

Inventory is shared per SKU.

Remaining stock must be greater than or equal to the requested quantity; otherwise overselling occurs.

Concurrent deductions must guarantee data consistency.

High QPS scenarios (e.g., flash sales) need high performance and availability.

Batch deduction for shopping‑cart orders must be transactional.

Refunds must return stock, ensuring idempotency and that the total returned amount does not exceed the deducted amount.

Database Deduction Scheme

Uses database features (optimistic lock, transactions) to ensure strong consistency with low development cost.

Relevant database features:

Optimistic lock (version or stock quantity) for concurrent deductions.

Transaction support for batch deductions, rolling back on partial failures.

Typical tables:

Field

Description

sku_id

SKU identifier

leaved_amount

Remaining purchasable quantity

Flow table records each deduction for auditing and potential refunds.

update inventory
set leaved_amount = leaved_amount - #{count}
where sku_id='123' and leaved_amount >= #{count}

The SQL relies on row‑level locking; a return value of 1 indicates success, otherwise the transaction is rolled back.

First Upgrade – Read‑Write Splitting

Introduce a replica database for inventory pre‑check, reducing load on the primary. The replica may lag, so the final stock validation still occurs on the primary using the optimistic‑deduction SQL.

Second Upgrade – Cache Layer

Introduce Redis as a cache for inventory checks, achieving ~10⁵ QPS read performance. The cache stores remaining stock (key: sku_leaved_amount_{sku_id} ) and deduction logs (hash inventory_flow_{sku_id} ). Lua scripts ensure atomic multi‑command execution.

-- Example Redis data model (simplified)
key: sku_leaved_amount_123   value: 57
hash: inventory_flow_123    field: order_detail_id   value: deducted_quantity

After a successful Redis deduction, the service asynchronously persists the change to the database.

Pure Cache Deduction Scheme

Relies entirely on Redis atomicity; suitable for extremely high QPS but lacks ACID guarantees, requiring extensive reconciliation and error handling.

Sharding (Database Partitioning) Scheme

Horizontally split the inventory table into multiple tables/databases, distributing load linearly. Each deduction and its corresponding flow record must reside in the same shard to maintain transactional consistency.

Other Approaches

Split hot SKUs across multiple databases using a hash of sku_id plus a random range.

Batch multiple deductions into a single update to reduce write pressure.

Use a message queue (e.g., RocketMQ) to decouple order creation from stock verification, at the cost of added latency.

Each solution balances consistency, performance, and complexity, and the appropriate choice depends on traffic volume, tolerance for data loss, and operational constraints.