Designing a High‑Concurrency Inventory System with Redis and Database to Prevent Overselling

When building an e‑commerce inventory system, the biggest concerns are high concurrency and preventing oversell. This article proposes a complete solution that integrates Redis for fast stock validation with a relational database for durable persistence, supplemented by a task‑engine to ensure eventual consistency.

Traditional Database‑Only Approach

Conventional designs rely on database transactions and an anti‑repeat table (antiRe) to guarantee that stock deductions are atomic and idempotent. However, under heavy traffic the database becomes a bottleneck, especially for hot‑selling items.

Redis‑Based Stock Check

The first “gate” moves the oversell check to Redis. By storing each SKU’s available quantity in a Redis hash, an HINCRBY operation atomically decrements the stock; a positive result means the purchase can proceed because Redis processes commands single‑threaded.

事务开始
Insert into antiRe(code) value (‘订单号+Sku’)
Update stockNum set num=num-下单数量 where skuId=商品ID and num-下单数量>0
事务结束

After the Redis check succeeds, the second “gate” simply persists the deduction to the database without re‑checking the quantity.

事务开始
Insert into antiRe(code) value (‘订单号+Sku’)
Update stockNum set num=num-下单数量 where skuId=商品ID
事务结束

Idempotency with Anti‑Repeat Codes

To guarantee idempotent deductions, a unique anti‑repeat code (e.g., order‑id+SKU) is stored using SETNX . If a network glitch occurs, the presence of this key determines whether the deduction succeeded.

// 初始化库存
127.0.0.1:6379> hset iphone inStock 1 # 设置库存为 1
127.0.0.1:6379> set a100_iphone "1" NX EX 10 # 防重码
127.0.0.1:6379> hincrby iphone inStock -1 # 扣减，返回 0 表示成功

Pipeline vs. Transaction

Using Redis Pipeline batches commands, reducing round‑trip latency while preserving result order. Although Redis transactions can also be used, pipelines are often faster for high‑throughput scenarios.

request → 执行 server将响应结果队列化
request → 执行 server将响应结果队列化
→ response
→ response

Task Engine for Final Consistency

A task engine records each deduction as a task, locks it (status = "locked"), and asynchronously persists the data to the appropriate sharded database. The engine supports split‑by‑order‑id, ensuring that hot‑item writes are distributed across multiple shards.

UPDATE 任务表_分表号 SET 状态 = 100, modifyTime = now() WHERE id = #{id} AND 状态 = 0

The engine also includes workers for exception handling, task unlocking, and recovery after server restarts, guaranteeing at‑least‑once execution.

Hot‑Item Throttling

To protect Redis from being overwhelmed by extremely hot SKUs, a JVM‑level rate limiter (e.g., Guava) can enforce a millisecond‑window limit (e.g., 10 ms → max 2 requests). This limits the pressure on Redis while still allowing thousands of orders per second across many servers.

Final Thoughts

The proposed architecture separates oversell validation (Redis) from durable persistence (database) and uses a task engine to achieve eventual consistency, providing a scalable solution for high‑traffic e‑commerce inventory management.