Designing High‑Concurrency Inventory Systems with Redis, Database Transactions, and a Task Engine

When developing an e‑commerce inventory system, the biggest concerns are high concurrency and preventing overselling; this article proposes a unified design that addresses both challenges.

Background – Traditional approaches rely on database transactions and anti‑repeat tables (antiRe) to ensure stock consistency, but they become a performance bottleneck under heavy traffic.

Redis‑based stock deduction – By moving the oversell check to Redis, each deduction uses hincrby on a hash field; a positive result means stock is sufficient, while a negative result triggers a rollback. Idempotency is achieved with a setnx anti‑repeat key (e.g., a100_iphone ) and optional pipelines for batch operations.

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

To handle the performance limits of a single Redis shard, a lightweight JVM‑level rate limiter (e.g., Guava) can throttle requests per 10 ms window, protecting Redis from hot‑SKU spikes.

Pipeline vs. Transaction – Pipeline batches commands to reduce round‑trip latency, while Redis transactions provide atomicity; the article recommends pipeline for speed and notes that transactions are slower.

request → execute (server queues response)
request → execute (server queues response)
→ response
→ response

Task Engine for eventual consistency – After the Redis deduction succeeds, a task engine asynchronously persists the final stock change to the relational database, using sharding and state machines to avoid hotspot contention. The engine guarantees at‑least‑once execution, supports task locking, retries, and failure recovery.

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

The overall flow consists of three steps: (1) lock and create a parent task, (2) execute external processing and generate child tasks within a transaction, and (3) schedule child tasks for execution. Workers handle exceptions, unlock stale tasks, and ensure continuity after server restarts.

Conclusion – By separating oversell validation (Redis) from persistence (database) and orchestrating the process with a robust task engine, the system achieves high‑throughput, low‑latency stock deduction while maintaining data accuracy and resilience.