SYSTEM DESIGN · QUESTION 118
How would you design an inventory service that avoids overselling?
On this page
I would define stock units, reservation duration, and consistency needs. Keep an authoritative inventory record and update it through atomic conditional writes or transactions; model available, reserved, and committed quantities separately. Use idempotent order requests, expiring reservations, and an event/outbox for downstream updates. Caches can serve catalog reads, but checkout must consult the authoritative reservation path.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A product page may show one item left to several shoppers at once. If each checkout reads the same number and decrements later, multiple orders can succeed for one item. The inventory update needs to be atomic, and reservations should expire if payment does not finish.
A USEFUL COMPARISON
Picture it this way
A theater attendant marks a seat as held before collecting payment. Other attendants must see the hold immediately, and it returns to availability if checkout expires. A stock service uses the same idea for a quantity of items.
FOLLOW THE JOURNEY
Reserve stock atomically before confirming an order
Show inventory state transitions, reservation expiry, and cache boundaries.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Search and catalog projections need eventual updates.
A checkout request atomically moves quantity from available to reserved, payment commits the order, and timeout releases the reservation; catalog cache is not authoritative.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Search and catalog projections need eventual updates.
UNDER THE HOOD
How it works, step by step
Read catalog view
Show cached product availability as an estimate.
Why it matters: Browsing reads can scale separately from checkout.
Reserve atomically
Conditionally decrement available and create a reservation.
Why it matters: Concurrent orders must not claim the same stock.
Commit or release
Confirm after payment or release on expiry/failure.
Why it matters: Temporary holds should not strand inventory.
Publish changes
Emit committed inventory events and refresh dependent views.
Why it matters: Search and catalog projections need eventual updates.
OUTSIDE THE TEXTBOOK
A practical example
Two checkouts race for the last unit. A conditional database update succeeds for one request and fails for the other. The winner holds the unit while payment runs; success commits the order, and a timeout releases the reservation. Product browse pages may temporarily show stale counts but checkout remains authoritative.
GO A LITTLE DEEPER
Technical details that matter
- Optimistic concurrency can use version numbers or conditional updates; pessimistic locks may limit throughput.
- An outbox can publish inventory changes reliably after the transaction.
- Oversell policy may differ for backorderable items versus scarce one-of-a-kind inventory.
MAKE A GOOD CHOICE
When is this useful?
- E-commerce checkout and scarce product allocation.
- Seat, room, or appointment reservations.
- Systems where concurrent writes race over limited capacity.
For high-volume approximate availability, a cached projection may be acceptable for browsing, paired with a strict reservation at purchase.
WATCH OUT FOR
Common misunderstandings
- Relying on a cached quantity for checkout.
- Separating check and decrement without atomicity.
- Never expiring abandoned reservations.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Strongly consistent reservation paths can become hot spots.
- Distributed stock across regions complicates consistency.
- Eventual catalog updates may briefly disagree with checkout.
WHAT TO REMEMBER
Key takeaways
- 1Keep checkout reservation authoritative and atomic.
- 2Represent available, reserved, and committed stock explicitly.
- 3Use expiries and idempotency to recover from failed payment flows.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
Can inventory browsing be eventually consistent?
Often yes, if checkout performs an authoritative reservation and handles sold-out responses clearly.
How do you scale a hot inventory item?
Partition or serialize reservations carefully, use admission control or queues, and avoid overselling by defining whether stock can be pre-allocated across regions.
SAY IT OUT LOUD
How to explain this in an interview
“I separate browse availability from authoritative checkout. The purchase path atomically reserves stock, tracks it separately from committed inventory, and confirms only after payment. Reservations expire and requests are idempotent so retries are safe. I would use caches for catalog reads but never rely on a stale cached quantity to prevent overselling.”
Connect this question to the roadmap topic it supports.