Designing a High-Concurrency Flash Sale Stock & Inventory Reservation System with Node.js, Redis, Lua, and MongoDB

Managing product inventory in e-commerce or high-concurrency systems can be tricky. What happens when 10,000 users try to buy the same product at the same time? Without careful design, you risk overselling, inconsistent stock counts, or database bottlenecks.

Without careful design, you risk overselling ❌, inconsistent stock counts 🤯, or database bottlenecks 🐌.

1. 🧐 Problem Statement

👉 Imagine a product with only 5 items in stock 📦.
If 20 people click “Buy” at the same time 🏃🏃🏃, how do we make sure only the first 5 succeed ✅ and the other 15 get out of stock ❌?

• MongoDB alone = too slow 🐢.
• Redis + Lua = lightning-fast ⚡ and safe 🛡️.

2. 🛠️ Core Concepts

• Redis 🧠 → Super fast in-memory DB (like a sticky note always ready).
• Lua Script 🧩 → Ensures atomic operations, no interruptions.
• Tokens 🎟️ → Each unit of stock is one token in Redis.
• MongoDB 📚 → Keeps long-term order + reservation data.
• Cron Jobs ⏰ → Small background workers that clean up expired reservations.

👉 Together = a safe stock system 🏗️.

3. 🔄 System Flow Diagram

👤 Client (User clicks Buy)
  │
  ▼
🟢 Node.js (Express API)
  │
  │ 1️⃣ Ask Redis for tokens
  ▼
🔴 Redis (Tokens per product)
  │
  │ 2️⃣ Lua script reserves tokens
  ▼
📦 MongoDB
  │
  │ 3️⃣ Save Order + Reservation
  ▼
⏰ Cron Job
  │
  │ 4️⃣ Expired order → tokens back
  ▼
🔴 Redis (stock restored)

👉 Think of Redis as a ticket counter 🎫, Mongo as the ledger 📒, and Cron as the cleaning robot 🤖.

4. 🎟️ Token-Based Stock Reservation

When seeding products, you push tokens into Redis:

await client.lpush("product:101:tokens", ["token:1","token:2","token:3"]);

• Each token = 1 unit of stock 📦.
• Buy 2 units → 2 tokens are popped out 🖐️🖐️.
• No tokens left → product is sold out 🚫.

👉 Super simple & visual = no overselling! 🎉

5. 🧩 Lua Script for Atomic Reservation

Why Lua? 🤔

Because if 1,000 users click buy at once 👥👥👥, normal loops fail.

Lua = all or nothing 🎯

-- Reserve tokens in one atomic step
if enough tokens → success ✅
else → rollback 🔄

👉 Think of Lua as a bouncer at the door 🚪:
Nobody sneaks in, everything is fair ✋.

6. 📚 MongoDB Orders & Reservations

Redis is fast but temporary ⚡🧠.
So we also save results in MongoDB for safety.

• Order 🧾 → Who bought what.
• Reservation 🗂️ → Which tokens are locked + expiry time ⏳.

👉 Mongo is like the history book 📖 so nothing gets lost if Redis resets.

7. ⏰ Handling Expiry with Cron Jobs

What if a user clicks buy but never pays? 💳❌

• Stock can’t stay locked forever ⛔.
• Solution: Cron Job runs every few seconds 🕐.
• Expired reservations → tokens go back to Redis ♻️.

👉 Cron = the janitor 🧹 cleaning unused tokens.

8. ⚖️ Pros & Cons

✅ Pros

• Super fast ⚡ (Redis in-memory).
• Atomic 🛡️ (Lua prevents race conditions).
• Scalable 📈 (works in flash sales).

❌ Cons

• More moving parts ⚙️ (Redis + Mongo + Cron).
• Must seed tokens correctly 🎟️.
• Sync issues if stock changes outside Redis 🔄.

👉 But overall → Worth it for high concurrency 💪.

9. 🏗️ Microservice Use

This design works beautifully in a microservice world 🌍:

• Product Service 🏪 → Seeds tokens in Redis.
• Order Service 📦 → Handles token reservation + Mongo save.
• Payment Service 💳 → Confirms payment, finalizes stock.

👉 Redis = the shared brain 🧠 for all services.

10. 🎯 Key Takeaways

• Redis + Lua = safe, atomic stock ops ⚡🛡️.
• Tokens = 🎟️ simple way to represent stock units.
• Mongo = 📚 history keeper.
• Cron = ⏰ auto cleanup robot 🤖.
• Perfect for 🛒 flash sales, ticketing systems 🎟️, and high-load apps 💥.

📖 Example Story (Easy to Imagine)

1. Product A has 3 items → Redis = [t1, t2, t3].
2. Alice buys 2 🛒 → gets [t1, t2].
3. Bob tries 2 → only [t3] left → Bob gets ❌ out of stock.
4. Alice doesn’t pay 😬 → Cron returns [t1, t2] to Redis.

👉 Always fair ✅, never oversells 🚫, and self-heals ♻️.

🔥 With Redis + Lua, your system can handle 10k+ concurrent buyers without overselling, while MongoDB + Cron ensures long-term consistency.