🎯 How Amazon Handles Inventory Sync
1️⃣ Core Inventory Framework (Staff-Level)
When discussing an Amazon-like inventory system, I frame it as:
- Inventory source of truth
- Available vs reserved vs sold stock
- Reservation lifecycle
- Warehouse and seller updates
- Event-driven propagation
- Reconciliation and correction
- Oversell protection
- Trade-offs: correctness vs latency vs availability vs throughput
2️⃣ Core Problem
Inventory is deceptively hard because many systems read and write stock:
- product detail page
- cart
- checkout
- payment
- warehouse systems
- returns
- seller systems
- cancellation flows
The system must avoid overselling while still serving high read traffic.
👉 Interview Answer
I would not model inventory as one mutable number. I would model it as a state machine with on-hand, reserved, sold, released, returned, and adjusted quantities. This makes checkout safer and makes reconciliation possible when distributed systems drift.
3️⃣ Inventory State Model
Common fields:
on_hand
reserved
available = on_hand - reserved - safety_stock
sold
returned
damaged
Important invariant:
available >= 0
4️⃣ Reservation Flow
User starts checkout
↓
Reserve inventory
↓
Payment attempt
↓
If payment succeeds: convert reservation to sold
If payment fails: release reservation
If timeout: expire reservation
👉 Interview Answer
Reservation protects the checkout path. Instead of decrementing final stock immediately, the system creates a temporary hold with a TTL. If payment succeeds, the hold becomes sold inventory. If payment fails or times out, the hold is released.
5️⃣ Consistency Boundaries
Use stronger consistency for:
- reserve
- release
- confirm sale
- refund or return adjustment
Use eventual consistency for:
- product page availability display
- search index availability
- analytics
- warehouse dashboards
👉 Interview Answer
I would use strong consistency in the checkout reservation path because overselling directly hurts customers. For product pages and search, eventual consistency is usually acceptable if we revalidate before checkout.
6️⃣ Event-Driven Sync
Inventory Change
↓
Inventory Event
↓
Message Bus
↓
Search Index / Catalog / Warehouse / Analytics
Events:
- StockReceived
- StockReserved
- ReservationExpired
- OrderConfirmed
- OrderCancelled
- StockReturned
- ManualAdjustment
7️⃣ Reconciliation
Why reconciliation is necessary:
- messages can be delayed
- warehouse counts can differ
- manual adjustments happen
- returns are messy
- third-party sellers report asynchronously
Reconciliation compares:
Inventory Ledger
vs
Warehouse Physical Count
vs
Order State
vs
Seller Feed
👉 Interview Answer
At scale, drift is unavoidable. The system needs a durable inventory ledger and reconciliation jobs that compare computed inventory with warehouse or seller truth, then create correction events instead of silently mutating state.
8️⃣ Oversell Protection
Patterns:
- atomic conditional update
- reservation token
- SKU-level lock for scarce items
- safety stock buffer
- queue or throttle for flash sale SKUs
- final validation before payment capture
9️⃣ Staff-Level Trade-offs
| Decision | Benefit | Cost |
|---|---|---|
| Strong checkout reservation | Prevents oversell | Adds latency and contention |
| Eventual read models | High read scale | Temporary stale availability |
| Safety stock | Reduces oversell | May hide sellable inventory |
| Ledger-based model | Auditable and correctable | More storage and complexity |
| Reconciliation jobs | Repairs drift | Operational overhead |
🔟 Failure Handling
Important failures:
- payment succeeds but inventory confirm fails
- inventory reserved but order abandoned
- duplicate reserve request
- delayed warehouse update
- seller feed sends stale quantity
Protections:
- idempotency key per checkout
- reservation TTL
- transactional outbox for inventory events
- compensating release events
- manual review for suspicious adjustments
中文部分
中文速记
一句话
Amazon Inventory 不能当成一个 stock number，而要设计成 available、reserved、sold、released、returned 的库存状态机。
背诵要点
- 商品页库存可以 eventual consistency
- checkout reserve 必须更强一致
- reservation 要有 TTL，支付失败或超时后释放
- 库存变化要通过 event 同步到 catalog、search、warehouse 和 analytics
- 大规模下 drift 一定会发生，所以 reconciliation 是必需的
中文面试回答
我不会把库存设计成一个简单的可变数字。 更好的做法是把库存建模成状态机，比如 on-hand、reserved、sold、released、returned 和 adjusted。 商品详情页和搜索页可以使用最终一致的库存视图，但 checkout 路径必须使用强一致的 reserve 操作，避免超卖。
用户进入 checkout 后，系统创建一个带 TTL 的 reservation。 如果支付成功，reservation 转成 sold。 如果支付失败、用户放弃或超时，reservation 被释放。 所有库存变化都应该写入 durable ledger，并发出 inventory events 给下游系统。
Staff 级重点是：分布式库存一定会出现漂移。 仓库、卖家、退货、取消和人工调整都会异步发生，所以系统必须有 reconciliation job，把库存 ledger、订单状态、仓库实物数量和卖家 feed 做对账。
✅ Final Interview Answer
An Amazon-like inventory sync system should be designed around reservations and an inventory ledger. Product pages and search can use eventually consistent availability, but checkout must reserve stock using a strongly consistent operation. The reservation has a TTL and transitions to sold only after payment succeeds. If checkout fails or expires, the reservation is released.
Inventory changes should emit events to update catalog, search, warehouse, and analytics systems. Because many systems update inventory asynchronously, reconciliation is required. At staff level, the key insight is that inventory correctness comes from explicit state transitions, idempotent operations, and continuous reconciliation, not from trusting a single cached stock number.
Implement