E-commerce Order Allocation Architecture (Amazon, eBay)

The Core Problem You open Amazon, add 3 items to your cart, and click “Checkout.” In a matter of milliseconds, the system must answer several complex questions simultaneously: Which warehouse should fulfill the order? — Item A is available in New York, Chicago, and Los Angeles. Where should it be shipped from? Consolidate or Split? — 3 items are in 3 different warehouses → ship as 3 separate packages (higher shipping cost) or transfer items internally to consolidate into 1 package (slower delivery)? Which driver delivers it? — Driver A is near the warehouse but their van is almost full. Driver B is further away but has a spacious truck. When to deliver? — Did the customer select 2-hour delivery, same-day, or standard (3-5 days)? This is not a simple CRUD operation. This is a Combinatorial Optimization problem — specifically NP-hard — and it is arguably more complex than Uber’s ride-matching algorithm. ...

The Order Lifecycle Every order on Amazon, eBay, or Shopify goes through 8 stages from the moment the customer clicks “Buy” until they receive the package: ┌─────────┐ ┌──────────┐ ┌───────────┐ ┌──────────┐ │ 1. ORDER │──►│ 2. PAYMENT│──►│ 3. FRAUD │──►│ 4. ALLOC │ │ CREATED │ │ AUTH │ │ CHECK │ │ ENGINE │ └─────────┘ └──────────┘ └───────────┘ └────┬─────┘ │ ┌─────────┐ ┌──────────┐ ┌───────────┐ ┌────▼─────┐ │ 8. DELI- │◄──│ 7. IN │◄──│ 6. PACKED │◄──│ 5. PICK │ │ VERED │ │ TRANSIT │ │ & LABELED │ │ & PACK │ └─────────┘ └──────────┘ └───────────┘ └──────────┘ Stage 1: Order Created — Intake Customer clicks "Buy Now" │ ▼ Validate: ✓ Are products in stock? (preliminary stock check) ✓ Is the shipping address valid? ✓ Is the payment method valid? ✓ Applied promo codes correctly? │ ▼ Create Order record in DB: order_id: "ORD-2026-05-06-001" status: PENDING items: [ {sku: "WATER-5L", qty: 2, capacity: 4}, -- 2 cases of 5L water, capacity = 4 {sku: "PHONE-X", qty: 1, capacity: 1}, -- 1 phone, capacity = 1 ] total_capacity: 5 customer_location: {lat: 40.71, lng: -74.00} delivery_sla: "SAME_DAY" Stage 2: Payment Authorization The system does not charge the money immediately. It only authorizes (places a hold on) the funds to ensure the customer has sufficient balance. The money is only captured (actually deducted) after the item ships. ...

Why is Inventory a Hard Problem? Imagine: A warehouse has exactly 1 iPhone left in stock. At 14:00:00.000, two customers in different cities click “Buy” simultaneously. If the system isn’t designed correctly, both orders are confirmed → overselling → one customer’s order will inevitably be canceled later → terrible user experience. This isn’t a theoretical issue; it happens daily across e-commerce platforms. Inventory Model: The 4 Types of Quantities For SKU: "IPHONE-16-256GB" at Warehouse NY: ┌──────────────────────────────────────────────────────────┐ │ Physical Stock (What's actually on shelves): 100 │ │ ├── Reserved (Held for pending orders): -15 │ │ ├── Safety Stock (Do not sell buffer): -5 │ │ │ │ │ └── Available to Sell (ATP): 80 │ │ (= Physical - Reserved - Safety) │ │ │ │ On-Order (Inbound shipments from suppliers): 50 │ │ Available to Promise (Future availability): 130 │ │ (= ATP + On-Order) │ └──────────────────────────────────────────────────────────┘ Type Meaning Who uses it? Physical Stock Actual physical items in the warehouse Warehouse team Reserved Items “held” for orders currently being processed but not yet shipped Allocation Engine Safety Stock Minimum buffer—never sold (accounts for damages, shrinkage) Inventory Manager ATP (Available to Sell) The actual number of items that can be sold immediately Storefront (shown to customers) Stock Reservation — Preventing Overselling The Reservation Flow Customer clicks "Buy": 1. Order Service → Inventory Service: "Reserve 1 IPHONE-16 at WH NY" 2. Inventory Service: BEGIN TRANSACTION SELECT atp FROM inventory WHERE sku = 'IPHONE-16' AND warehouse = 'NY' FOR UPDATE; -- Pessimistic lock IF atp >= 1: UPDATE inventory SET reserved = reserved + 1 WHERE ... INSERT INTO reservations (order_id, sku, qty, expires_at) VALUES ('ORD-001', 'IPHONE-16', 1, NOW() + INTERVAL '30 minutes'); RETURN: RESERVED ELSE: RETURN: OUT_OF_STOCK COMMIT 3. If RESERVED: Proceed to payment checkout If OUT_OF_STOCK: Notify customer item is unavailable Reservation Expiry — Auto-Release If the customer holds the item in their cart but abandons checkout for 30 minutes, the reservation expires automatically: ...

The Three Sub-Problems Allocating orders to drivers is essentially a combination of three classic optimization problems: Step 1: ASSIGNMENT — Which order goes to which driver? Step 2: BIN PACKING — How many orders can fit in a driver's vehicle? (capacity constraint) Step 3: VRP — What is the optimal route for the driver to deliver them? (routing) In practice, all three are often solved simultaneously. Problem 1: Assignment Problem Definition Given N orders and M drivers, every (order, driver) pair has an associated cost (distance, time, or money). Find an assignment that minimizes the total cost. ...

Amazon Fulfillment: The Three Tiers of Optimization Amazon processes billions of orders annually through a network of over 175 fulfillment centers globally. To maintain their 1-2 day (or same-day) delivery guarantees, they built a 3-tier optimization architecture: ┌─────────────────────────────────────────────────────────────┐ │ TIER 1: ANTICIPATORY SHIPPING (Long-term — weeks/months) │ │ → ML predicts demand → Moves inventory close to customers │ │ BEFORE they place an order │ ├─────────────────────────────────────────────────────────────┤ │ TIER 2: REGIONALIZATION (Medium-term — days/weeks) │ │ → Partitions the fulfillment network into autonomous zones│ │ → Ensures 70-80% of orders are fulfilled intra-region │ ├─────────────────────────────────────────────────────────────┤ │ TIER 3: CONDOR (Short-term — hours) │ │ → Continuously re-optimizes the fulfillment plan within │ │ a 5-6 hour window before pick-and-pack begins. │ └─────────────────────────────────────────────────────────────┘ Anticipatory Shipping — Shipping Before You Buy A Crazy but Effective Idea Amazon holds a patent (US Patent 8,615,473) describing a system that begins shipping items BEFORE a customer places an order. It sounds like science fiction, but it’s a reality. ...

Split vs. Consolidation — The Core Trade-off When a customer’s order contains multiple items, and those items reside in different warehouses, the system faces a classic logistics dilemma: Order: 3 items (A in WH New York, B in WH Chicago, C in WH Miami) Destination: Customer in New York Option 1: SPLIT SHIPMENT (Ship directly from 3 warehouses) WH NY → Customer: Item A (1 box) — $3.00, 2 hours WH Chicago → Customer: Item B (1 box) — $8.50, 2 days WH Miami → Customer: Item C (1 box) — $6.50, 1.5 days Total: $18.00, 3 separate deliveries, 3 boxes Option 2: CONSOLIDATE (Transfer internally, ship once) WH Chicago → WH NY: Item B (internal) — $4.00, 1 day WH Miami → WH NY: Item C (internal) — $3.50, 1 day WH NY → Customer: A+B+C (1 box) — $4.50, 2 hours Total: $12.00, 1 delivery, 1 box, BUT delayed by 1-2 days The Trade-off: Fast & Expensive vs. Slow & Cheap Decision Matrix Factor Favors Split Favors Consolidation SLA Requirements Urgent (same-day, 2-hour) Standard (3-5 days) Shipping Costs Customer pays for shipping Free shipping (Platform absorbs cost) Customer Preference Wants items ASAP Wants everything in one box Order Value Small items (not worth consolidating) Large orders (significant savings) Item Type Perishables / Medical supplies Non-urgent dry goods The Split/Consolidate Algorithm Function: decideFulfillmentStrategy(order, warehouses) // Step 1: Is there a single warehouse with ALL items? single_source = findWarehouseWithAllItems(order.items, warehouses) if single_source exists: return SINGLE_SOURCE(single_source) // The ideal scenario // Step 2: Calculate costs for both strategies split_cost = calculateSplitCost(order) consolidate_cost = calculateConsolidateCost(order) // Step 3: Check SLA bounds if order.sla == "SAME_DAY" or order.sla == "2_HOURS": return SPLIT // No time to transfer inventory internally // Step 4: Compare cost vs. delay savings = split_cost - consolidate_cost consolidation_delay = estimateConsolidationDelay(order) // Only consolidate if savings exceed a threshold AND delay is acceptable if savings > THRESHOLD and consolidation_delay <= order.max_acceptable_delay: return CONSOLIDATE else: return SPLIT Last-Mile Delivery — The Most Expensive Mile The last-mile is the final leg of delivery from the local distribution hub to the customer’s doorstep. Even though it’s usually just a few miles, it accounts for 53% of total logistics costs. Why? ...

Problem Statement Answer-first: This guide builds a complete Vehicle Routing Problem (VRP) allocation engine using Google OR-Tools in Python. The engine assigns delivery orders to drivers respecting min/max capacity constraints, guarantees EXPRESS orders are delivered first (1,000,000× penalty), and minimizes total fleet distance — wrapped in a FastAPI microservice. You are a software engineer at a logistics company. Every day, the warehouse dispatches hundreds of orders. You need to allocate these orders to a fleet of drivers such that: ...

Series context: This is Part 7 of the E-commerce Order Allocation series. The distance matrix built here feeds directly into the OR-Tools VRP solver in Part 6. The Invisible yet Most Expensive Bottleneck in E-commerce Routing Answer-first: For 1 warehouse + 100 delivery stops, you need 10,201 pairwise distances. Self-hosting GraphHopper or OSRM on a $20/month VPS delivers this in under 50ms per batch — completely free. Using Google Maps Distance Matrix API for the same workload costs $510/day. This guide shows you exactly when to use which tool, with Docker setup and production Python code. ...