Flash sale thương mại điện tử

Redis đơn luồng nên một Lua script kiểm tra giới hạn mỗi người và DECR là nguyên tử, xử lý hàng chục nghìn lần/s. Chỉ người thắng mới được đẩy vào queue; worker ghi đơn bằng UPDATE có điều kiện nên DB vẫn là chốt chặn cuối. Đơn huỷ hoặc quá hạn thì cộng lại cả hai nơi; job đối soát so sánh Redis với DB mỗi phút.

Đánh đổi: Redis và DB có thể lệch (Redis failover mất vài lần DECR, worker lỗi giữa chừng), nên cần đối soát; người dùng thấy 'đang xử lý' thay vì kết quả tức thì.

Nguồn: Redis in Action ↗ · ch.11 · §11.3 Doing away with WATCH/MULTI/EXEC (Lua, tr. 260–265) ; Redis in Action ↗ · ch.6 · §6.2 Distributed locking (tr. 116–127) ; Grokking Modern System Design · ch.17 Distributed Messaging Queue ↗ · bài "System Design: The Distributed Messaging Queue", mục "Motivation" (Rate limiting: hấp thụ đột biến) ; Redis in Action ↗ · ch.4 · §4.3 Handling system failures (tr. 75–78: Redis có thể mất dữ liệu khi failover)

Purchase API chỉ làm việc nhẹ (Redis + đẩy message) và trả 202; queue (Grokking ch.17) giữ phần còn lại để worker ghi DB theo tốc độ ổn định. Khi số người vượt mức, đưa vào phòng chờ có số thứ tự. Khi SKU đã hết trong Redis, gateway trả 410 ngay từ cờ sold_out mà không gọi vào trong. Ưu tiên luồng thanh toán hơn luồng xem khi phải cắt tải.

Đánh đổi: Kết quả trả về bất đồng bộ, client phải poll hoặc nghe push; thêm queue và phòng chờ để vận hành.

Nguồn: Grokking Modern System Design · ch.17 Distributed Messaging Queue ↗ · bài "System Design: The Distributed Messaging Queue", mục "Motivation" (Rate limiting: hấp thụ đột biến) ; Building Microservices ↗ (.zip) · ch.11 Microservices at Scale · mục "Degrading Functionality" (tr. 207–208) ; Grokking Modern System Design · ch.23 Distributed Task Scheduler ↗ · bài "Design Considerations", mục "Prioritization" ; Chưa có nguồn trong thư viện: phòng chờ (waiting room) ở edge không có trong sách

Ghi payment, đổi trạng thái order có điều kiện (WHERE status='PENDING_PAYMENT') và ghi outbox trong cùng một transaction (Microservices Patterns §3.3.7). Relay đẩy outbox lên Kafka với at-least-once, consumer lưu id sự kiện đã xử lý để bỏ bản trùng (§3.3.6). Huỷ đơn quá hạn là bước bù của saga (ch.4).

Đánh đổi: Thêm bảng outbox, relay và bảng processed_messages; đổi lại không mất, không trùng tác dụng.

Nguồn: Microservices Patterns ↗ (.zip) · ch.3 · §3.3.7 Transactional messaging (tr. 97–100) ; Microservices Patterns ↗ (.zip) · ch.3 · §3.3.6 Handling duplicate messages (tr. 95–97), mục "Tracking messages and discarding duplicates" ; Microservices Patterns ↗ (.zip) · ch.4 · §4.1.3 và §4.2 Coordinating sagas (tr. 114–126)

Phần tĩnh hoàn toàn trên CDN. Phần động (phần trăm đã bán) cache trong bộ nhớ mỗi pod 1 s, nên 167 pod chỉ gửi khoảng 167 lần đọc/s xuống Redis. Với key bị ghi nóng như stock thì chia thành N sub-key (stock:{deal}:0..9) nằm trên nhiều shard, mỗi request chọn ngẫu nhiên một sub-key, hết thì thử sub-key khác. Grokking ch.16 nêu hot key và gợi ý sharding tiếp trong dải key đó hoặc thêm replica; ý tưởng chia sub-key giống sharded counters ở Grokking ch.24.

Đánh đổi: Số lượng hiển thị trễ 1-2 s; sub-key làm logic hết hàng phức tạp hơn (có sub-key hết trước trong khi tổng vẫn còn).

Nguồn: Grokking Modern System Design · ch.16 Distributed Cache ↗ · bài "Evaluation of a Distributed Cache's Design", mục "Scalability" (replica cho hot shard, sharding tiếp trong dải key nóng) ; Grokking Modern System Design · ch.24 Sharded Counters ↗ · bài "Detailed Design of Sharded Counters" (chia một counter nóng thành nhiều shard, chọn ngẫu nhiên khi ghi) ; Redis in Action ↗ · ch.2 · §2.3 Web page caching (tr. 30–31)