Kiến trúc Phân bổ Đơn hàng E-commerce (Amazon, eBay)

Bài toán cốt lõi Bạn mở Shopee, đặt 3 món hàng, bấm “Thanh toán”. Trong vài mili-giây, hệ thống phải trả lời đồng thời: Kho nào gửi? — Món A có ở kho Hà Nội, kho TP.HCM, và kho Đà Nẵng. Gửi từ đâu? Gộp hay tách? — 3 món ở 3 kho khác nhau → gửi 3 kiện riêng (tốn thêm phí ship) hay chuyển hàng nội bộ để gom 1 kiện (chậm hơn)? Tài xế nào giao? — Tài xế A đang gần kho nhưng xe gần đầy. Tài xế B cách xa hơn nhưng xe rộng rãi. Giao khi nào? — Khách chọn giao trong 2 giờ hay giao tiết kiệm (3-5 ngày)? Đây không phải bài toán CRUD. Đây là bài toán tối ưu hóa tổ hợp (Combinatorial Optimization) — thuộc loại NP-hard — phức tạp hơn cả bài toán matching của Uber. ...

Vòng đời đơn hàng (Order Lifecycle) Mỗi đơn hàng trên Amazon, Shopee hay Lazada đều trải qua 8 giai đoạn từ lúc khách bấm “Mua” đến lúc nhận hàng: ┌─────────┐ ┌──────────┐ ┌───────────┐ ┌──────────┐ │ 1. ORDER │──►│ 2. PAYMENT│──►│ 3. FRAUD │──►│ 4. ALLOC │ │ CREATED │ │ AUTH │ │ CHECK │ │ ENGINE │ └─────────┘ └──────────┘ └───────────┘ └────┬─────┘ │ ┌─────────┐ ┌──────────┐ ┌───────────┐ ┌────▼─────┐ │ 8. DELI- │◄──│ 7. IN │◄──│ 6. PACKED │◄──│ 5. PICK │ │ VERED │ │ TRANSIT │ │ & LABELED │ │ & PACK │ └─────────┘ └──────────┘ └───────────┘ └──────────┘ Giai đoạn 1: Order Created — Tiếp nhận đơn Khách bấm "Mua hàng" │ ▼ Validate: ✓ Sản phẩm còn hàng? (preliminary stock check) ✓ Địa chỉ giao hàng hợp lệ? ✓ Phương thức thanh toán hợp lệ? ✓ Có mã giảm giá? Áp dụng đúng? │ ▼ Tạo Order record trong DB: order_id: "ORD-2026-05-06-001" status: PENDING items: [ {sku: "WATER-5L", qty: 2, capacity: 4}, -- 2 thùng nước 5L, capacity = 4 {sku: "PHONE-X", qty: 1, capacity: 1}, -- 1 điện thoại, capacity = 1 ] total_capacity: 5 customer_location: {lat: 10.77, lng: 106.70} delivery_sla: "SAME_DAY" Giai đoạn 2: Payment Authorization — Xác thực thanh toán Hệ thống không charge tiền ngay. Nó chỉ authorize (giữ tiền) để đảm bảo khách có đủ số dư. Tiền chỉ bị capture (trừ thật) sau khi hàng được gửi đi. ...

Tại sao tồn kho là bài toán khó? Tưởng tượng: kho còn 1 chiếc iPhone cuối cùng. Lúc 14:00:00.000, hai khách hàng ở hai thành phố khác nhau cùng bấm “Mua” đồng thời. Nếu hệ thống không xử lý đúng, cả hai đều được xác nhận → overselling → một khách sẽ bị hủy đơn → trải nghiệm tệ, mất khách. Đây không phải vấn đề lý thuyết — đây là vấn đề xảy ra hàng ngày trên mọi sàn e-commerce. ...

Ba bài toán con Phân bổ đơn hàng cho tài xế thực chất là tổng hợp của 3 bài toán kinh điển: Bước 1: ASSIGNMENT — Đơn nào cho tài xế nào? Bước 2: BIN PACKING — Mỗi tài xế nhận bao nhiêu đơn? (capacity constraint) Bước 3: VRP — Tài xế đi giao theo lộ trình nào? (routing) Trong thực tế, cả 3 bước thường được giải đồng thời. Bài toán 1: Assignment Problem (Bài toán phân công) Định nghĩa Cho N đơn hàng và M tài xế, mỗi cặp (đơn, tài xế) có một chi phí (khoảng cách, thời gian, hoặc tiền). Tìm cách phân công sao cho tổng chi phí nhỏ nhất. ...

Amazon Fulfillment: Ba lớp tối ưu Amazon xử lý hàng tỉ đơn hàng mỗi năm qua mạng lưới hơn 175 fulfillment centers trên toàn thế giới. Để đạt được cam kết giao hàng 1-2 ngày (hoặc cùng ngày), họ xây dựng hệ thống tối ưu hóa 3 tầng: ┌─────────────────────────────────────────────────────────────┐ │ LỚP 1: ANTICIPATORY SHIPPING (Dài hạn — tuần/tháng) │ │ → ML dự đoán nhu cầu → Di chuyển hàng đến gần khách │ │ TRƯỚC KHI đặt hàng │ ├─────────────────────────────────────────────────────────────┤ │ LỚP 2: REGIONALIZATION (Trung hạn — ngày/tuần) │ │ → Chia mạng lưới kho thành vùng tự trị │ │ → Đảm bảo 70-80% đơn hàng được giao nội vùng │ ├─────────────────────────────────────────────────────────────┤ │ LỚP 3: CONDOR (Ngắn hạn — giờ) │ │ → Tái tối ưu fulfillment plan liên tục trong cửa sổ 5-6h │ │ → Gom đơn, tối ưu lộ trình, giảm chi phí │ └─────────────────────────────────────────────────────────────┘ Anticipatory Shipping — Gửi hàng trước khi đặt Ý tưởng điên rồ nhưng hiệu quả Amazon có bằng sáng chế (US Patent 8,615,473) mô tả hệ thống bắt đầu vận chuyển hàng TRƯỚC KHI khách đặt đơn. Nghe như science fiction nhưng đây là thực tế. ...

Split vs. Consolidation — Trade-off cốt lõi Khi đơn hàng có nhiều món nhưng các món nằm ở nhiều kho khác nhau, hệ thống phải đối mặt với quyết định kinh điển: Đơn hàng: 3 món (A ở kho HN, B ở kho HCM, C ở kho ĐN) Giao cho khách ở Hà Nội Phương án 1: SPLIT (Tách gửi từ 3 kho) Kho HN → Khách: A (1 kiện) — 30.000đ, 2 giờ Kho HCM → Khách: B (1 kiện) — 85.000đ, 2 ngày Kho ĐN → Khách: C (1 kiện) — 65.000đ, 1.5 ngày Tổng: 180.000đ, 3 lần giao, 3 hộp Phương án 2: CONSOLIDATE (Gom về 1 kho rồi gửi) Kho HCM → Kho HN: B (nội bộ) — 40.000đ, 1 ngày Kho ĐN → Kho HN: C (nội bộ) — 35.000đ, 1 ngày Kho HN → Khách: A+B+C (1 kiện) — 45.000đ, 2 giờ Tổng: 120.000đ, 1 lần giao, 1 hộp, nhưng chậm hơn 1-2 ngày Trade-off: Nhanh + tốn vs. Chậm + tiết kiệm Decision Matrix Yếu tố Ưu tiên Split Ưu tiên Consolidate SLA Giao nhanh (same-day, 2h) Giao tiêu chuẩn (3-5 ngày) Chi phí Khách trả phí ship Free shipping (seller chịu) Trải nghiệm Khách cần gấp từng món Khách muốn nhận đủ 1 lần Giá trị đơn Đơn nhỏ (không đáng gom) Đơn lớn (gom tiết kiệm đáng kể) Loại hàng Hàng tươi/khẩn cấp Hàng khô, không gấp Thuật toán quyết định Split/Consolidate Function: decideFulfillmentStrategy(order, warehouses) // Bước 1: Kiểm tra xem có kho nào có ĐỦ tất cả items không single_source = findWarehouseWithAllItems(order.items, warehouses) if single_source exists: return SINGLE_SOURCE(single_source) // Lý tưởng nhất // Bước 2: Tính chi phí cho mỗi phương án split_cost = calculateSplitCost(order) consolidate_cost = calculateConsolidateCost(order) // Bước 3: Kiểm tra SLA if order.sla == "SAME_DAY" or order.sla == "2_HOURS": return SPLIT // Không đủ thời gian gom // Bước 4: So sánh chi phí savings = split_cost - consolidate_cost consolidation_delay = estimateConsolidationDelay(order) // Chỉ gom nếu tiết kiệm > ngưỡng VÀ delay chấp nhận được if savings > THRESHOLD and consolidation_delay <= order.max_acceptable_delay: return CONSOLIDATE else: return SPLIT Last-Mile Delivery — Chặng cuối đắt đỏ Last-mile là chặng cuối từ hub/kho đến tay khách hàng. Dù chỉ dài vài km, nó chiếm 53% tổng chi phí logistics vì: ...

Mô tả bài toán Bạn là kỹ sư tại một công ty giao hàng. Mỗi ngày, kho xuất ra hàng trăm đơn hàng. Bạn cần phân bổ các đơn hàng cho đội ngũ tài xế sao cho: Đầu vào 1 kho duy nhất (Điểm xuất phát - Depot). N tài xế, mỗi tài xế có: min_capacity: Số đơn vị tối thiểu phải nhận (để chuyến đi có lời). max_capacity: Sức chứa tối đa (giới hạn vật lý: trọng lượng, thể tích). M đơn hàng, mỗi đơn hàng có: capacity_cost: Số đơn vị capacity chiếm dụng (ví dụ: 1 thùng nước = 3, 1 điện thoại = 1). destination: Vị trí giao hàng (để tính khoảng cách). priority: Mức ưu tiên (EXPRESS, STANDARD). Ràng buộc thực tế 1. Capacity Constraint: ∀ driver d được sử dụng: min_capacity(d) ≤ tổng_capacity_đơn ≤ max_capacity(d) 2. Đảm bảo giao hàng: Phải cố gắng giao nhiều đơn nhất có thể. Nếu quá tải, ưu tiên rớt các đơn STANDARD lại, tuyệt đối không rớt đơn EXPRESS. 3. Objective (Mục tiêu): Minimize tổng quãng đường giao hàng của toàn bộ tài xế. Bước 1: Database Schema Vẫn giữ nguyên schema chuẩn như thiết kế ban đầu để quản lý trạng thái: ...

Mảnh ghép vô hình nhưng tốn kém nhất Trong phần trước, khi chạy Google OR-Tools, chúng ta truyền vào một biến có tên là distance_matrix. Nghe có vẻ đơn giản, nhưng để OR-Tools có thể tìm ra lộ trình tốt nhất, nó cần biết khoảng cách giữa tất cả các điểm với nhau. Nếu bạn có 1 kho và 100 đơn hàng, tổng số điểm là 101. Số lượng cặp khoảng cách cần tính là 101 × 101 = 10,201 (hơn 10 nghìn lượt tính toán). ...