Amazon has thousands of warehouses. When you order a product, the system checks which warehouses have it in stock, selects the optimal fulfillment location, and reserves that unit. Multi-location inventory is different from seat inventory consistency: seats are identical and interchangeable, but warehouse location matters for delivery time and shipping cost. The same product at a warehouse 2,000 miles away is not the same as one 50 miles away.

The Data Model#

Inventory is per-SKU per-warehouse: (sku_id, warehouse_id, quantity_available, quantity_reserved). A single SKU with stock at 100 warehouses has 100 rows. Total available = sum across all warehouse rows.

Reserving one unit: pick the optimal warehouse (closest to customer, cheapest shipping, in-stock), then UPDATE inventory SET quantity_reserved = quantity_reserved + 1 WHERE sku_id = X AND warehouse_id = W AND quantity_available > quantity_reserved. If rows affected = 0, that warehouse is out of stock; try the next candidate.

Warehouse Selection#

Selecting the optimal warehouse is a multi-factor optimization: delivery time (distance from warehouse to customer), shipping cost (carrier rates from this warehouse), stock level (avoid warehouses nearly out of stock), and current workload (avoid overwhelmed warehouses during peak).

This is computed before the reservation step, producing an ordered list of candidate warehouses. The reservation attempt works down the list until one succeeds.

graph TD A[Customer orders SKU: 12345, zip: 94105] --> B[Find warehouses with stock] B --> C[Rank by distance + cost + load] C --> D[Attempt reservation: warehouse Oakland] D --> E{Success?} E --> |Yes| F[Reserve confirmed: ship from Oakland] E --> |No: out of stock| G[Attempt reservation: warehouse Los Angeles] G --> H{Success?} H --> |Yes| I[Reserve confirmed: ship from LA] H --> |No| J[Try next warehouse or split shipment] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style H fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style I fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style J fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

Split Shipments#

An order for 3 units of a product might require drawing from multiple warehouses: 2 from Oakland, 1 from Los Angeles. The system must handle partial fulfillment from a single warehouse and combine with reservations from others. Split shipments are common for large orders during high-demand periods.

The reservation is now a multi-step saga: reserve from warehouse A, then reserve from warehouse B. If B’s reservation fails, release the A reservation. Saga pattern with compensating transactions handles this.

Global vs Regional Inventory Counts#

The total available count shown on the product page (“3 left in stock”) is a global aggregate across all warehouses, but it doesn’t need to be exact. An approximate count (computed every few minutes from a read replica) is fine for display purposes. The exact count only matters at reservation time, and that uses the per-warehouse row-level check.

Stale global counts lead to “we’re sorry, this item is no longer available” after checkout — a degraded but acceptable experience compared to the complexity of strong consistency for display counts.

At Oracle#

Oracle Field Service (cloud-based service scheduling) had a similar problem: tools and parts inventory at field technician vehicles. A part ordered for a job needed to be reserved from the technician’s specific van, not a central warehouse. Each van was a “warehouse.” Reservation logic was identical: check van inventory, reserve the specific unit, track via serial number. The key difference from warehouse inventory: van inventory couldn’t be replenished mid-day, so out-of-stock was a hard failure requiring job rescheduling.

What I’m Learning#

Multi-location inventory is fundamentally about accepting that the optimal fulfillment location may not be available, and having a fallback strategy. The reservation loop down a ranked warehouse list handles this gracefully. The hard case is large orders requiring split shipments, where saga-style multi-step reservation becomes necessary.

Have you designed inventory systems with multiple fulfillment locations, and what failure mode caused the most operational pain?