Holdfast — Inventory Reservation Engine
A backend engine that never oversells inventory under concurrency — the core correctness problem in quick-commerce. It benchmarks three concurrency-control strategies against real Postgres and proves the no-oversell guarantee with tests.
Performance & Impact
0
Oversells
500 concurrent buyers vs 50 units — exactly 50 win, proven for all 3 strategies
~4,200/s
Throughput
Reservations/sec on a single hot row (local Postgres benchmark, median of 3)
12 passing
Tests
Concurrency, idempotency, deadlock-safe baskets, lifecycle, chaos — vs real Postgres
The Problem
Quick-commerce lives and dies on inventory correctness: when 500 people tap “buy” on the last 50 units at once, a naïve read-check-write oversells. Most demos hand-wave this by running a single process and claiming it scales.
The Solution
A real reservation engine where the no-oversell guarantee is proven, not claimed — 500 concurrent buyers, exactly the available quantity wins, asserted for three different concurrency-control strategies that are benchmarked head-to-head so the trade-offs are measured, not guessed.
System Architecture
Holdfast solves the hardest correctness problem in quick-commerce (Zepto / Blinkit / Instamart): when hundreds of customers race for the last few units of a SKU, exactly the available quantity must succeed — never one more. It implements three concurrency-control strategies (pessimistic SELECT … FOR UPDATE, optimistic version compare-and-swap, and an atomic conditional UPDATE) behind one interface and benchmarks them against real Postgres. Order placement is idempotent via a UNIQUE idempotency key, so a retried request never double-reserves. Multi-item baskets reserve atomically with deadlock-safe global lock ordering. A reservation lifecycle (HOLD → CONFIRMED / RELEASED) with a background expiry sweeper returns abandoned holds to stock. Schema and migrations are model-driven via Drizzle, while the reservation hot path deliberately uses raw SQL so the locking stays explicit. Prometheus metrics expose throughput, latency, and optimistic retry counts.
Core Engineering Achievements:
System Architecture
API
Concurrency Engine
Data
Observability & Ops
"A reservation is one transaction: idempotency guard, inventory decrement via the chosen strategy, then a HELD order row. The atomic conditional UPDATE is the default — its WHERE clause is the guard, so no read-modify-write race exists. Baskets acquire rows in a single global order (sorted by SKU) so concurrent carts can't form a lock cycle."
The Engineering Challenge
The most interesting problem was deadlock-safe basket reservation. Reserving several SKUs atomically invites deadlocks: cart A locks milk then eggs while cart B locks eggs then milk, and Postgres aborts one. Acquiring rows in a single global order (sorted by SKU) makes a lock cycle impossible — the test fires 100 baskets locking the same two SKUs in opposite order with zero deadlocks. The other key call was keeping raw SQL on the hot path: Drizzle owns the schema and migrations, but the FOR UPDATE / conditional-atomic / version-CAS locking is hand-written, because an ORM hides exactly the behaviour the project exists to demonstrate.
User Journey
Interested in the full engineering breakdown?
I'm always open to discussing technical implementations, from state management strategies to infrastructure scaling.