Flash sale — tổng quan case chống bán quá số lượng
Một SKU, 1.000 sản phẩm, hàng chục nghìn người bấm mua trong vài giây: case này đi từ ràng buộc tới ba quyết định lõi, mỗi quyết định kèm cái giá.
TL;DR: Case này đặt một bài toán cụ thể: 1.000 sản phẩm, 200.000 người chờ, một nửa bấm mua trong 2 giây đầu, và không được bán quá dù chỉ một đơn. Bạn sẽ tự đo trần của một row tồn kho trên Postgres của mình, tái hiện lỗi bán quá, rồi tự chọn ba quyết định trên ba trục khác nhau: cơ chế trừ trên một row, thời gian giữ hàng, và cách xử lý tải đổ vào. Mỗi lựa chọn đều có một cái giá được nêu ra và đo ra.
Sáu giờ chiều, đội marketing báo tối nay mở bán 1.000 chiếc. Câu UPDATE items SET stock = stock - 1 nghe đủ cho việc đó, cho đến khi 100.000 người bấm trong hai giây. Module này đi từ chỗ "nghe đủ" tới chỗ biết chính xác nó vỡ ở đâu, vì sao, và sửa bằng cách đổi lấy cái gì.
Bài toán và bảng ràng buộc
Bảng dưới là bản rút gọn của bảng ở bài 01. Bốn bài sau trích lại đúng bộ số này, không đặt số mới.
| Ràng buộc | Giá trị |
|---|---|
| Hàng | 1 SKU, tồn kho 1.000 |
| Người chờ lúc mở bán | 200.000, một nửa bấm trong 2 giây đầu |
| Không bán quá | 0 đơn vượt 1.000 |
| Phản hồi còn hay hết | p99 dưới 1 giây (99 trong 100 lượt phản hồi nhanh hơn 1 giây) |
| Giữ chỗ | 10 phút, 30% người giữ chỗ bỏ không trả tiền |
| Một người | Tối đa 1 sản phẩm |
Hai dòng "0 đơn bán quá" và "p99 dưới 1 giây" kéo ngược chiều nhau, và cả module xoay quanh việc giữ cả hai.
Sau module này bạn sẽ
- Ước lượng được tải đỉnh của một đợt bán giới hạn và trần thông lượng của một row tồn kho nóng bằng số đo trên máy mình.
- Chẩn đoán được vì sao tính tồn kho bằng đếm đơn rồi ghi vẫn bán quá số lượng dù đã bật transaction.
- Chọn được cơ chế trừ tồn kho trên một row Postgres theo thời gian giữ khoá và tỉ lệ thử lại dưới ràng buộc đã đặt.
- Thiết kế được luồng giữ chỗ có hạn trả lại tồn kho bị giữ mà không thanh toán và không trừ trùng.
- Chọn được giữa chặn tải ở cửa và nâng trần của hàng nóng khi tải vượt trần hàng chục lần.
- Biện luận được vì sao một hệ thống thật chọn khác thiết kế của bạn dựa trên ràng buộc của họ.
Lộ trình sáu bài, mỗi bài một vai
- Bài 01, ràng buộc và ước lượng: chốt bảng số, tính tải đỉnh, tự đo trần một row bằng
pgbench. Chưa có thiết kế nào, chỉ có số. - Bài 02, phương án ngây thơ: thiết kế đơn giản nhất, bạn tự đếm số đơn bán quá nó gây ra.
- Bài 03, cơ chế trên một row: quyết định thứ nhất, trục "trừ thế nào".
- Bài 04, thời gian giữ hàng: quyết định thứ hai, trục "trừ lúc nào và giữ bao lâu".
- Bài 05, tải đổ vào: quyết định thứ ba, trục "bao nhiêu người được chạm vào hàng nóng".
- Bài 06, đối chiếu thực tế: các hệ thống thật chọn gì, và ràng buộc nào của họ khác bảng của bạn.
Bài 07, tổng kết ráp ba quyết định thành một thiết kế hoàn chỉnh và gom các cái giá vào một bảng.
Cần chuẩn bị gì
Bạn cần đã học khoá sql-database, nhất là phần transaction và isolation level, vì case này <Recall> lại chúng thay vì dạy lại. Về công cụ: Postgres chạy bằng Docker và pgbench (đi kèm bản cài Postgres, hoặc dùng trong container). Số đo khác máy, nên bài dạy theo tỉ lệ, và máy bạn cho số khác là bình thường.
Cách học ở tuyến này
Ba thói quen, lặp lại ở mọi bài:
- Tự quyết trước khi đọc lời giải. Gặp
<DesignChoice>thì chọn một phương án rồi mới đọc phần phân tích. - Mọi lựa chọn có cái giá. Câu cần luyện là "cái giá nào ràng buộc của tôi gánh được", không phải "đâu là đáp án đúng".
- Tự đo. Mỗi bài có một script nhỏ chạy trên Postgres của bạn. Con số của chính bạn thuyết phục hơn con số trong bài.
Bắt đầu với bài 01.
Bài này có giúp bạn hiểu bản chất không?
Bài này đáng gửi cho bạn học cùng?
Copy link đã gắn nguồn — dán group, chat, hoặc LinkedIn.
Thảo luận & góp ý
Hỏi đáp về bài này