System Design: Inventory Management

Design an inventory management system for a grocery marketplace. The interviewer focuses on stock updates, item reservation, shopper collect-item API calls, database schema, and high consistency. Requirements Functional requirements: Track available inventory for (retailer/store, item). Update stock from retailer feeds, shopper actions, refunds/cancellations, and manual corrections. Reserve items when a customer checks out so two orders do not consume the same stock. Expose an API for the shopper app to collect, replace, or mark an item unavailable. Release or adjust reservation when an order is canceled, expired, partially fulfilled, or replaced. Scale / constraints: Grocery inventory is high-churn and correctness-sensitive. Popular items can see many concurrent carts and shopper updates. Reservation must be strongly consistent for hot SKUs; stale availability is acceptable for browsing but not for checkout. The system must tolerate retailer feed delays and shopper offline periods. Core APIs: GET /stores/{store_id}/items/{item_id}/availability POST /orders/{order_id}/reserve POST /orders/{order_id}/items/{item_id}/collect POST /orders/{order_id}/items/{item_id}/replace POST /reservations/{reservation_id}/release Data model: inventory(store_id, item_id, available_qty, reserved_qty, version, updated_at) reservation(reservation_id, order_id, store_id, item_id, qty, state, expires_at) inventory_event(event_id, source, store_id, item_id, delta, version, created_at) Notes Split browse availability from checkout reservation. Browse can read from cache/search index; checkout reservation must hit the inventory authority. Use conditional updates or serializable transactions for reservation: reserve only if available_qty >= requested_qty, then decrement available and increment reserved in the same transaction. Add reservation TTL. If checkout or shopper assignment does not complete, a background job releases expired reservations. For shopper collect-item calls, use idempotency keys keyed by (order_id, item_id, action, client_event_id) so offline retries do not double-apply deltas. High consistency does not mean every read is strongly consistent. Keep strong consistency at state transitions: reserve, collect, replace, cancel, refund. Conflict policy matters: retailer feed says qty=0 while a shopper just collected one. Preserve event source and version; do not blindly overwrite. A last-write-wins feed can corrupt order state. Deep-dive trade-offs: SQL row locks vs DynamoDB conditional writes, per-store-item sharding for hot SKUs, event log for audit/reconciliation, and cache invalidation for browse results. Preparation Draw the data model first; interviewers repeatedly focus on schema and consistency. Prepare the reservation transaction in pseudocode. Have a clear answer for offline shopper updates: client event id, at-least-once sync, conflict resolution, and reconciliation job. Practice the hot-item scenario where 100 carts attempt to reserve the last unit.