"During a flash sale, 100,000 users try to buy the same product simultaneously. How do you implement inventory deduction that is both high-performance and accurate — no overselling, no underselling?"
Inventory accuracy under extreme concurrency is one of e-commerce's hardest problems. Overselling creates terrible customer experience and legal issues; underselling means lost revenue. This question tests your ability to combine caching, atomic operations, and distributed systems knowledge into a practical solution.
Explain why naive database-level locking fails at this scale: lock contention makes throughput collapse.
Describe the Redis + Lua atomic deduction approach for the hot path.
Cover the async reconciliation flow: Redis deduction → message queue → database confirmation.
Address edge cases: what happens when Redis and the database disagree? How do you handle refunds?
I'd implement a three-layer inventory system. Layer 1 — Pre-filtering: before the sale starts, load the total inventory count into Redis. On each request, a Lua script atomically checks if inventory > 0 and decrements. This handles the hot path with sub-millisecond latency and rejects over-limit requests immediately. The Lua script ensures atomicity without distributed locks. Layer 2 — Async order creation: successful Redis deductions produce a message to RocketMQ. Order service consumers create the actual order and deduct from the database within a local transaction. If the database deduction fails (e.g., data inconsistency), a compensation message returns the Redis inventory. Layer 3 — Reconciliation: a scheduled job runs every 30 seconds comparing Redis inventory count against database confirmed orders. Any discrepancy triggers an alert and auto-correction. For preventing overselling specifically, I'd set the Redis inventory slightly below actual stock (e.g., 99% of real inventory) as a safety buffer, with the remaining 1% available only through the database path for latecomers. Refunds reverse the flow: database credit first, then Redis increment via message queue.
The Redis Lua script is the key insight — mention it explicitly and explain why it's better than distributed locks.
Always address the reconciliation problem — interviewers want to know you think about data consistency beyond the happy path.
Mention the "oversell vs. undersell" trade-off: slight underselling is commercially preferable to any overselling.
WATCH/MULTI uses optimistic locking which causes many retries under high contention. A Lua script executes atomically on the Redis server without round-trips, providing both atomicity and much better throughput under concurrent access.
Use Redis Sentinel or Cluster for high availability. If the master fails, the replica promotes within seconds. During the brief failover window, requests can be queued or fast-failed with a "please retry" message. Post-recovery, reconcile Redis state from the database.
HireMe AI listens to your interview in real-time, detects questions, and generates instant answer suggestions — so you never freeze up again.
Try HireMe AI Free