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.
Kiến trúc tổng thể
┌───────────────────────────────────────────────────────────────────┐
│ CUSTOMER │
│ "Mua 3 món hàng, giao trong 2 giờ" │
└──────────────────────────┬────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ ORDER MANAGEMENT SYSTEM (OMS) │
│ │
│ ┌────────────────┐ ┌────────────────┐ ┌─────────────────────┐ │
│ │ Order Intake │ │ Payment Check │ │ Fraud Detection │ │
│ │ (Validate) │ │ (Authorize) │ │ (Risk Score) │ │
│ └───────┬────────┘ └───────┬────────┘ └─────────┬───────────┘ │
│ └───────────────────┼──────────────────────┘ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ ORDER ALLOCATION ENGINE │ │
│ │ │ │
│ │ Input: │ │
│ │ - Order items (SKU, quantity, dimensions, weight) │ │
│ │ - Customer location │ │
│ │ - Delivery SLA (2h / same-day / 3-5 ngày) │ │
│ │ │ │
│ │ Queries: │ │
│ │ - Inventory Service → Kho nào còn hàng? │ │
│ │ - Driver Pool → Tài xế nào rảnh? Capacity bao nhiêu? │ │
│ │ - Routing Service → Chi phí + thời gian mỗi lộ trình │ │
│ │ │ │
│ │ Output: │ │
│ │ - Fulfillment Plan: [{kho, items, driver, route}] │ │
│ └───────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Warehouse A │ │ Warehouse B │ │ Warehouse C │
│ (Hà Nội) │ │ (TP.HCM) │ │ (Đà Nẵng) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
┌──────────────────────────────────────────┐
│ DRIVER POOL │
│ Driver 1: capacity 50kg, đang tại kho A │
│ Driver 2: capacity 30kg, đang giao hàng │
│ Driver 3: capacity 80kg, rảnh tại kho B │
└──────────────────────┬───────────────────┘
│
▼
┌──────────┐
│ CUSTOMER │
│ 📦 Nhận │
└──────────┘
Năm trụ cột của hệ thống
1. Order Fulfillment — Hành trình từ “Mua” đến “Nhận”
Hiểu rõ toàn bộ vòng đời đơn hàng: từ khi khách bấm mua → validate → authorize payment → chọn kho → pick & pack → handoff cho tài xế → giao hàng → xác nhận.
2. Inventory Management — Tồn kho thời gian thực
Không thể phân bổ đơn nếu không biết chính xác hàng còn bao nhiêu ở đâu. Hệ thống tồn kho phải giải quyết: overselling (bán vượt số lượng), reserved stock (hàng đã giữ cho đơn chưa thanh toán), safety stock (hàng dự phòng).
3. Thuật toán phân bổ — Bộ não của hệ thống
Ba họ thuật toán cốt lõi:
- Assignment Problem (Hungarian Algorithm): Phân bổ 1-1 tối ưu.
- Bin Packing: Xếp nhiều đơn vào tài xế sao cho tối ưu capacity.
- Vehicle Routing Problem (VRP): Tìm lộ trình tối ưu cho nhiều tài xế.
4. Amazon CONDOR & Anticipatory Shipping
Hai hệ thống kinh điển của Amazon:
- CONDOR: Tái tối ưu phương án fulfillment liên tục trong cửa sổ 5-6 giờ.
- Anticipatory Shipping: Dùng ML dự đoán và chuyển hàng đến gần khách TRƯỚC KHI đặt hàng.
5. Split Shipment & Last-Mile Delivery
Quyết định gộp/tách đơn và tối ưu hóa giao hàng chặng cuối — phần tốn kém nhất (chiếm 53% tổng chi phí logistics).
So sánh với bài toán khác
| Đặc điểm | Uber Matching | Order Allocation |
|---|---|---|
| Đối tượng | 1 khách ↔ 1 tài xế | N items ↔ M kho ↔ K tài xế |
| Ràng buộc | Vị trí, vehicle type | Tồn kho, capacity, SLA, chi phí |
| Thời gian quyết định | < 2 giây | Vài ms → 6 giờ (CONDOR) |
| Hàm mục tiêu | Minimize ETA | Minimize (cost + time), subject to SLA |
| Loại bài toán | Assignment Problem | Bin Packing + VRP + Assignment |
| Dữ liệu vật lý | Không (digital matching) | Có (hàng tồn kho, trọng lượng, kích thước) |
Bài thực hành cuối cùng: Mini Order Allocation Engine
Ở phần 6, bạn sẽ xây dựng một hệ thống phân bổ đơn hàng hoàn chỉnh với điều kiện:
- 1 kho duy nhất (đơn giản hóa bài toán chọn kho).
- N tài xế, mỗi tài xế có min capacity và max capacity.
- Mỗi đơn hàng có capacity cost riêng (có thể > 1, ví dụ: đơn 3 thùng nước = capacity 3, đơn 1 điện thoại = capacity 1).
- Mục tiêu: phân bổ đơn hàng cho tài xế sao cho:
- Tất cả đơn được giao.
- Không tài xế nào vượt max capacity.
- Mỗi tài xế phải nhận ít nhất min capacity (để chuyến đi có lời).
- Tổng chi phí/thời gian nhỏ nhất.
Bắt đầu hành trình với Phần 1 — Order Fulfillment: Từ click “Mua hàng” đến giao tận tay.