Flipkart Marketplace Platform  ·  View 15 of 25  ·  5 · Runtime

Inventory Reservation Lifecycle

The hardest component in the marketplace, drawn as the loop it actually is.

Editable source SVG draw.io All views
Available Redis counter Reserved TTL 900 s Confirmed ledger row written Allocated node and wave Fulfilled handover scan Reconciled count vs ledger One SKU at one node reserve · Lua CAS payment authorised fulfilment engine picks node picked and packed delivered, RTO or return drift correction, hourly Inventory — The Reservation Loop That Prevents Overselling Data store Application we own Opportunity Security / platform Expiry and cancellation return units to Available on the same path as reconciliation, so there is exactly one way stock comes back. v 1.0 · owner Commerce Engineering · date 2026-09

How overselling is prevented

  • A single Redis key per listing per node holds the available count; the decrement is a Lua script, so check and decrement are one atomic operation
  • Every reservation is a row with a TTL; the durable ledger in Citus is written on confirm, not on reserve
  • Reconciliation runs hourly and corrects drift in one direction only — the ledger wins over the counter

The alternative that was rejected

  • Optimistic concurrency straight onto PostgreSQL: correct, simple, and it collapses when 100k requests contend on one hot SKU
  • Distributed locks: a lock held across a payment redirect is a lock held for minutes, which is not a lock
  • The chosen design accepts a cache as the contention point and pays for it with a reconciliation job

Risks

  • A Redis failover loses in-flight reservations; they are rebuilt from the reservation log with a brief oversell window on the affected SKUs
  • Reconciliation drift is a business metric, not just an ops one — it is on the war-room board during sale events
  • Seller-side stock that is also sold off-platform can never be perfectly accurate; SLA breaches, not oversells, are the observable