Design Flash Sale & Inventory (Blinkit / Amazon Last-Unit Race)

01 /Problem framing

In quick-commerce platforms like Blinkit, Zepto, and Instamart, inventory is strictly localized to a specific neighborhood dark store. A dark store in Indiranagar, Bengaluru or Sector 56, Gurgaon holds roughly 5,000 active SKUs in a 3,000 square foot facility.

On a Sunday morning at 08:30 AM, breakfast demand surges. In the Indiranagar dark store, exactly one 500g packet of Amul butter remains on the shelf.

Asha and Ben both have that packet in their carts. Both tap "Place Order and Pay ₹58" at the exact same millisecond.

If your inventory engine has a concurrency race:

• Both payments succeed.
• Two delivery riders are dispatched to the same shelf.
• One rider gets the butter; the other rider finds an empty rack.
• Customer support must call Ben to apologize, initiate a refund, and offer a ₹50 coupon. In quick commerce, overselling destroys customer trust and unit economics.

The architectural challenge is: how do you guarantee that a finite physical item is sold to exactly one buyer under concurrent web traffic, while keeping catalog browsing fast and checkout latency under 50 milliseconds?

02 /Questions I ask before drawing anything

03 /Requirements

Below the line (Scope exclusions)

To preserve focus on high-concurrency inventory reservation and flash sale consistency during an interview, declare these items out of scope:

• Warehouse picker physical route optimization: Slicing picking tasks and calculating Traveling Salesperson paths through dark store aisles are handled by warehouse management software.
• Supply chain demand forecasting & automated re-stocking: Machine learning models predicting tomorrow's banana replenishment volumes run in offline analytics clusters.
• Supplier invoice reconciliation & returns: Generating credit notes for expired FMCG stock is part of back-office enterprise ERP systems.

04 /Estimation

Notice an essential architectural truth: while national volume is high (150,000 reads/sec), concurrency on a single physical item in a single dark store is bounded. Sharding by store_id distributes the load across your cluster.

05 /API design

1. Reserve Stock Hold (Proceed to Payment)

POST /v1/inventory/reserve
Host: inventory.quickcommerce.internal
Content-Type: application/json
Idempotency-Key: idemp_hold_99182a

{
  "store_id": "BLR_IND_04",
  "user_id": "usr_asha_42",
  "ttl_seconds": 300,
  "items": [
    { "sku_id": "SKU_AMUL_500G", "quantity": 1 },
    { "sku_id": "SKU_BREAD_WHEAT", "quantity": 1 }
  ]
}

Response (201 Created - All items reserved):

{
  "hold_id": "hld_01HZX8921KL",
  "status": "RESERVED",
  "expires_at": "2026-04-12T08:35:00Z",
  "items": [
    { "sku_id": "SKU_AMUL_500G", "reserved_qty": 1 },
    { "sku_id": "SKU_BREAD_WHEAT", "reserved_qty": 1 }
  ]
}

Response (409 Conflict - Item Out of Stock):

{
  "error": "INSUFFICIENT_STOCK",
  "unavailable_items": [
    { "sku_id": "SKU_AMUL_500G", "requested": 1, "available": 0 }
  ]
}

2. Confirm Deduction (Payment Webhook Capture)

POST /v1/inventory/confirm
Host: inventory.quickcommerce.internal
Content-Type: application/json

{
  "hold_id": "hld_01HZX8921KL",
  "payment_reference": "pay_upi_88192a8b",
  "confirmed_at": "2026-04-12T08:32:15Z"
}

Response (200 OK):

{
  "status": "DEDUCTED",
  "hold_id": "hld_01HZX8921KL"
}

3. Release Hold (Explicit Cancel or Webhook Failure)

POST /v1/inventory/release
Host: inventory.quickcommerce.internal
Content-Type: application/json

{
  "hold_id": "hld_01HZX8921KL",
  "reason": "PAYMENT_FAILED_INSUFFICIENT_FUNDS"
}

06 /Database schema

A relational store (PostgreSQL) guarantees transactional consistency for physical inventory counts.

CREATE TABLE store_inventory (
    store_id VARCHAR(32) NOT NULL,
    sku_id VARCHAR(64) NOT NULL,
    total_physical INT NOT NULL DEFAULT 0,
    available INT NOT NULL DEFAULT 0,
    reserved INT NOT NULL DEFAULT 0,
    sold INT NOT NULL DEFAULT 0,
    safety_buffer INT NOT NULL DEFAULT 1,
    version INT NOT NULL DEFAULT 1,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    PRIMARY KEY (store_id, sku_id),
    CONSTRAINT chk_available_nonneg CHECK (available >= 0),
    CONSTRAINT chk_reserved_nonneg CHECK (reserved >= 0)
);

CREATE TABLE inventory_holds (
    hold_id VARCHAR(64) PRIMARY KEY,
    store_id VARCHAR(32) NOT NULL,
    user_id VARCHAR(64) NOT NULL,
    sku_id VARCHAR(64) NOT NULL,
    quantity INT NOT NULL,
    status VARCHAR(32) NOT NULL DEFAULT 'HELD',
    expires_at TIMESTAMPTZ NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_holds_expiry ON inventory_holds (expires_at, status);

07 /Concurrency strategies: from broken to bulletproof

Let us trace the four approaches to handling the last unit race.

1. Naive Read-Modify-Write (The bug that causes overselling)

// BROKEN: Race condition between read and write
const item = await db.query(
  'SELECT available FROM store_inventory WHERE store_id = $1 AND sku_id = $2',
  [storeId, skuId]
);

if (item.available >= 1) {
  // Concurrency window: Both Asha and Ben reach here simultaneously!
  await db.query(
    'UPDATE store_inventory SET available = $1 WHERE store_id = $2 AND sku_id = $3',
    [item.available - 1, storeId, skuId]
  );
  return { status: 'RESERVED' };
}

If Asha and Ben read available = 1 at the exact same millisecond, both threads pass the if check. Both write available = 0. Both are promised the packet. One packet was sold twice.

2. Pessimistic Locking (SELECT FOR UPDATE)

BEGIN;
SELECT available 
FROM store_inventory 
WHERE store_id = 'BLR_IND_04' AND sku_id = 'SKU_AMUL_500G' 
FOR UPDATE;

-- Application checks if available >= 1, then updates:
UPDATE store_inventory 
SET available = available - 1 
WHERE store_id = 'BLR_IND_04' AND sku_id = 'SKU_AMUL_500G';
COMMIT;

FOR UPDATE locks the database row. Ben's query blocks until Asha's transaction commits.

• The problem: Holding open database row locks while application code processes payment gateways or network calls causes connection pool starvation and severe throughput degradation.

3. Atomic Conditional Update (The relational sweet spot)

You do not need an open transaction lock. You can let the database evaluate the condition atomically in the SQL engine:

UPDATE store_inventory
SET available = available - 1,
    reserved = reserved + 1,
    version = version + 1
WHERE store_id = 'BLR_IND_04' 
  AND sku_id = 'SKU_AMUL_500G' 
  AND available >= 1;

In PostgreSQL or MySQL, an UPDATE statement acquires an exclusive row lock only for the microsecond duration of the row modification.

• If Asha runs this first: 1 row is updated. Her application sees rowCount == 1 and proceeds.
• When Ben runs this second: The condition available >= 1 fails. The database updates 0 rows. Ben's application sees rowCount == 0 and immediately responds: "Sorry, this item just went out of stock".

Zero race conditions, zero deadlocks, zero dirty reads.

4. Redis Two-Phase Reservation with TTL (High scale flash sales)

During flash sales where 10,000 users click on a single discounted product, hitting PostgreSQL directly can overwhelm connection pools.

We use Redis with an atomic Lua script:

-- KEYS[1]: store:BLR_IND_04:sku:SKU_AMUL_500G
-- ARGV[1]: hold_qty (1)
-- ARGV[2]: hold_id (unique UUID)
-- ARGV[3]: hold_ttl_seconds (300)

local current = tonumber(redis.call('HGET', KEYS[1], 'available') or '0')
if current >= tonumber(ARGV[1]) then
    redis.call('HINCRBY', KEYS[1], 'available', -tonumber(ARGV[1]))
    redis.call('HINCRBY', KEYS[1], 'reserved', tonumber(ARGV[1]))
    -- Record hold ownership and expiry
    redis.call('SET', 'hold:' .. ARGV[2], ARGV[1], 'EX', ARGV[3])
    return 1 -- SUCCESS
else
    return 0 -- OUT OF STOCK
end

08 /Interactive race simulator

Step through Asha and Ben racing for the last packet of Amul butter. Test the naive strategy to see the double-promise bug, switch to conditional updates, and test what happens when payment fails under a TTL reservation hold.

09 /Physical reality: phantom inventory and safety buffers

Software architectures assume that physical inventory strictly equals the database number. In a physical warehouse or dark store, this assumption is false.

• Damaged goods: A rider picks up an egg carton and notices one cracked egg.
• Misplaced stock: A picker placed the butter on the ice cream shelf. The system thinks it exists, but the picker cannot find it within the 2-minute picking window.
• Shrinkage: Inventory theft or miscounting during supplier inwarding.

The Safety Buffer strategy

For high-velocity or perishable goods, many quick commerce teams apply a virtual floor:

• Sellable count = max(0, physical_available - safety_buffer).
• If safety_buffer = 1, when physical count reaches 1, the app displays: "Out of Stock".
• That final unit serves as insurance against damaged packaging. If an existing order has a damaged piece, the picker substitutes that buffer unit rather than canceling the customer order.

10 /Edge cases and failure recovery

1. Payment Callback Arrives after 5-Minute TTL Expiration

Asha enters her UPI PIN slowly. Her payment captures at minute 6, but the hold sweeper already expired her reservation and released the butter to Ben.

• Compensating Transaction: The payment webhook detects the hold state is EXPIRED. It checks physical inventory; if another unit exists, it claims it. If zero units remain, it automatically issues an instant UPI reversal refund and notifies the customer: "Item sold out during payment; refund initiated".

2. Multi-Item Cart Atomic Hold Rollback

A cart contains Milk, Bread, and Butter. Milk and Bread are reserved, but Butter fails because only 0 units remain.

• The reservation service immediately rolls back the holds on Milk and Bread in the same execution cycle, preventing inventory from getting stranded across partial orders.

3. Warehouse Floor Damage During Picking

A picker accidentally drops a bottle of olive oil.

• The picker hits "Mark Damaged" on the handheld scanner. An inward deduction event updates store_inventory to decrement total_physical and available, preventing downstream orders from racing for a broken bottle.

11 /Cross-questions interviewers will ask

12 /Interview Rubric: Mid-Level vs Senior / Staff