Design a Shopping Cart Service That Keeps Inventory Consistent Under Concurrency
Company: Headway
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Technical Screen
Design the backend that manages shopping carts for an online store: shoppers add items, change quantities, remove items, view their cart and check out. Expect the interviewer to move quickly past the cart itself to inventory consistency: how the design keeps stock counts correct when many shoppers want the same items, and what a cart can promise about availability.
### Constraints and Clarifications
- Assume checkout charges the shopper through an external payment provider.
- Not given: traffic, catalog size, how long carts live, whether guests can have carts, how many locations hold stock, and whether an item may ever be oversold. Ask, or state your assumptions.
### Clarifying Questions
- Does adding an item to the cart hold stock for the shopper, or is stock taken only at checkout?
- Must an item never be oversold, or are backorders acceptable for some items?
- Are there limited-quantity drops or sales in which thousands of shoppers want the same item at once?
- Do guests have carts, and must a cart follow a signed-in shopper across devices?
- Is stock held in one location or in many?
### Part 1 — Cart data model and API
Define how carts are stored and the API for adding, updating, removing, viewing and checking out. Decide what the cart stores as fact and what it only displays.
```hint Intent versus facts
Price and stock change after an item is added. Decide which of them the cart should own and which it should look up.
```
#### What This Part Should Cover
- Cart storage, keys and partitioning, including guest carts and merging at sign-in
- Cart operations that are safe to retry
- How the price and availability shown in the cart stay honest without being treated as guarantees
### Part 2 — Preventing overselling
Two shoppers try to buy the last unit of an item at the same moment. Explain when your design takes stock (at add-to-cart, at the start of checkout, or after payment), the exact operation that decides who gets the last unit, and how stock held for a shopper who never finishes is returned.
```hint One write decides
Find the single atomic operation that can succeed for only one of the two shoppers, and check that there is no gap between reading the stock and writing it.
```
```hint Holds must end
Decide how long stock may be held for an unfinished checkout, and what returns it when the shopper never comes back.
```
#### What This Part Should Cover
- The inventory data model: units in stock versus units held
- The atomic reserve operation and its behavior under concurrency, including carts with several items
- Hold expiry and release, and the race between expiry and a late payment
- The trade-offs of taking stock at add-to-cart, at checkout, or after payment
### Part 3 — Checkout across services, failures and hot items
Checkout touches the cart, inventory, payment and orders. Walk through the end-to-end flow and what happens when any step fails or is retried. Then explain what breaks when a single popular item receives a burst of purchase attempts, and how you would handle it.
```hint Every step can be repeated
Assume any call can time out after it actually succeeded. Decide what makes repeating each step harmless, and what undoes a step when a later one fails.
```
#### What This Part Should Cover
- An end-to-end checkout flow with idempotency and compensation for partial failures
- Whether a distributed transaction across these services is appropriate, and why
- Contention on one item's stock record, and at least one technique to relieve it
- Reconciliation and monitoring that would reveal oversold units or leaked holds
### What a Strong Answer Covers
- Clarifies the reservation and overselling policies before choosing a design
- Keeps carts highly available while keeping stock strongly consistent, and explains why the two differ
- A concrete atomic stock operation with no check-then-act race
- Hold expiry, idempotent retries and compensation, traced through failure cases
- Hot-item contention and observability, with the trade-offs stated
### Follow-up Questions
- Stock is now spread across several warehouses. How do reservation and displayed availability change?
- The cart showed an item as in stock, but checkout fails for lack of stock. How do you make that rare, and how is it presented to the shopper?
- How would you detect and repair drift between the stock count and the orders actually placed?
- A shopper changes the quantity of an item after checkout has started. What happens to the existing hold?
Overview: Design the backend for an online store's shopping cart, with the focus on inventory consistency: when stock is reserved, how two shoppers racing for the last unit are resolved, and how abandoned holds are released. It tests data modeling, concurrency control, checkout failure handling and contention on popular items.