Zero-Downtime Inventory Reservations Under High Concurrency

Zero-Downtime Inventory Reservations Under High Concurrency

One of the most difficult problems in e-commerce engineering is maintaining absolute stock integrity during sudden traffic spikes.

Imagine launching a rare seafood drop or a festive 50% discount promotion. Thousands of shoppers arrive within sixty seconds. Five hundred customers add the last twenty units of a coveted product to their carts simultaneously.

If your database uses naive read-modify-write patterns, you will oversell. If you use heavy pessimistic database row locks, your database CPU spikes to 100%, requests time out, and checkout freezes.

Why Pessimistic Database Locks Fail at Scale

In a traditional relational or document database pattern:

1. Request A starts a transaction and locks the product row.
2. Request B, C, and D attempt to read and lock the same row.
3. Network latency between the payment gateway webhook and your API keeps rows locked for several seconds.
4. Connection pools exhaust, HTTP 504 Gateway Timeouts cascade across the server, and the entire shop goes down.

The Sliding-Window Redis Reservation Model

To solve this, Dariyo implements a two-tier inventory architecture:

• Tier 1: High-Speed Atomic Memory (Redis) handles instantaneous cart reservations and decrementing locks.
• Tier 2: Durable Persistence (MongoDB) records finalized, paid order transitions and permanent stock ledgers.

The Atomic Reservation Flow

When a buyer initiates checkout, an atomic Lua script executes inside Redis:

// Conceptual atomic reservation logic
interface StockReservation {
  variantId: string;
  quantity: number;
  cartToken: string;
  expiresAt: number; // Unix timestamp: now + 15 minutes
}

1. Atomic Availability Check: The Lua script evaluates whether available = (total_stock - active_reservations) >= requested_quantity.
2. Key Assignment with TTL: If available, a reservation key is stamped with a strict time-to-live (TTL) of 15 minutes.
3. Instant Cart Feedback: The customer enters their payment flow knowing their items are safely reserved for the duration of the payment session.

Graceful Release of Abandoned Carts

What happens when a shopper abandons their browser tab or fails payment?

• No background manual cleanup is required.
• The Redis TTL expires naturally.
• The background scheduler (scheduler.service.ts) periodically synchronizes expired holds and releases reservations back to the active catalog.
• If the customer completes payment through Razorpay, the webhook promotes the temporary reservation into a permanent order deduction.

This architecture guarantees that inventory is never oversold, lock contention is zero, and the platform comfortably sustains thousands of requests per second on standard cloud droplets.