Flipkart Marketplace Platform · View 15 of 25 · 5 · Runtime
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