## Design an Inventory Management System Design a system that tracks products and stock across one or more locations, supports receipts, reservations, releases, adjustments, and fulfillment, and exposes current availability and movement history. Clarify whether the exercise concerns a warehouse, store shelves, or both before fixing the model. ### Part 1 — Define Stock and Operations Specify product, location, stock ledger, reservation, and order identities plus APIs for receiving, reserving, releasing, committing, adjusting, and querying inventory. #### What This Part Should Cover - Separate on-hand, reserved, and available quantities. - Positive quantities, reason codes, and stable operation IDs. - Idempotent retries and immutable movement evidence. - Lot, expiration, serial, or unit-cost fields only when required. ```hint Make availability an equation Define which durable facts contribute to available stock before exposing a single mutable count. ``` ### Part 2 — Prevent Overselling Design the atomic reservation path under concurrent requests and explain reservation expiry, partial availability, cancellation, and fulfillment. #### What This Part Should Cover - Conditional stock updates or row-level transactions. - One commit boundary for reservation state and inventory movement. - Expiring holds with race-safe release or commit. - A declared all-or-nothing or partial-reservation contract. ```hint Compete on one version Two callers may both observe enough stock, so the winning reservation must change a version or quantity condition that invalidates the loser. ``` ### Part 3 — Scale Reads and Writes Partition the authoritative data, support transfers between locations, build availability projections, and handle hot products, retries, and downstream consumers. #### What This Part Should Cover - Product-location keys and transfer state spanning two locations. - An outbox or ledger stream for derived search and availability views. - Versioned caches with stated staleness. - Hot-key mitigation that preserves the oversell invariant. ```hint Keep the ledger authoritative A fast availability cache can lag, but the reservation decision must still use state that can reject an oversell. ``` ### Part 4 — Reconcile and Operate Explain physical counts, corrections, audit, replay, metrics, and tests for failure at each boundary. #### What This Part Should Cover - Append-only corrections rather than erased history. - Recomputable balances and projection reconciliation. - Alerts for negative stock, stale reservations, and event lag. - Concurrency, duplicate, transfer, expiry, and recovery tests. ```hint Correct with another movement An adjustment should explain why the balance changed while preserving the earlier evidence needed for audit. ``` ### What a Strong Answer Covers - Precise inventory states and atomic reservation semantics. - Durable idempotent movements with no overselling. - Repairable projections and explicit cache consistency. - Transfers, expiration, physical reconciliation, and observability. ### Follow-up Questions 1. How would you reserve inventory across several products atomically? 2. What happens if fulfillment succeeds physically but its acknowledgement is lost? 3. How would you represent stock in transit between locations? 4. Which source wins when a physical count disagrees with the ledger?