Katkat
Back

Design an Inventory Service with Reservations, Hot SKUs and Oversell Prevention

InstacartSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

A system design question about an inventory management service that reserves stock while customers check out. It tests how a candidate prevents overselling under concurrent updates, handles hot SKUs, manages reservation expiry and idempotency, and supports partial fulfillment of multi-item orders.

Design an inventory management service for an online ordering platform. The service tracks how much stock of each product (SKU) is available, reserves stock while a customer's order is being placed, and then either commits the reservation when the order is fulfilled or releases it when the order is cancelled or abandoned. Orders usually contain several SKUs.

The discussion is expected to go deep on:

  • Concurrency: many orders updating the same stock at the same time.
  • Hot SKUs: a few products that receive a large share of the traffic.
  • Reservations: holding stock for an order between checkout and fulfillment.
  • Overselling: never promising more units than exist.
  • Partial fulfillment: what happens when only part of an order can be satisfied.

Clarifying Questions

  • Is stock tracked per location (store or warehouse) as well as per SKU, and how is the location for an order chosen?
  • Where do stock changes come from: deliveries, stock counts, external systems? How closely does the recorded count match the shelf?
  • How long may a reservation hold stock before it expires?
  • When only part of an order is available, what should happen: fulfill what is available, offer substitutes, split the order, or fail it?
  • What scale should the design handle: number of SKUs and locations, peak order rate, and the peak rate for the single hottest SKU?
  • Is slightly stale availability acceptable on browsing pages, as long as checkout is exact?

Hints

Hint 1

Model the states of a unit: Before choosing storage, write down which states a unit of stock can be in and which events move it between them; most of the concurrency discussion follows from that.

Hint 2

One SKU, many buyers: Think about what serializes updates when many checkouts target the same SKU at the same moment, and whether that serialization point can be split or moved.

Follow-up questions

  • A flash sale sends far more demand to one SKU than there is stock. How does the design protect both the database and the user experience?
  • A stock count shows fewer units than are already reserved for confirmed orders. What happens?
  • How would you run this service across several regions, and where does the source of truth for one location's stock live?
  • How do you make sure a retried reserve call from the order service never reserves stock twice?