Idempotency

Khi một khách hàng bấm nút đặt hàng trên nền tảng Composable Commerce, có tới 7 sự kiện bắt buộc phải diễn ra theo chuỗi vắt ngang qua 4 service hoàn toàn độc lập: Tạo Đơn hàng (Order created) → Duyệt Thanh toán (Payment authorized) → Giữ chỗ Tồn kho (Stock reserved) → Kích hoạt Giao nhận (Fulfillment triggered) → Bắn Thông báo (Notification sent) → Cộng Điểm thưởng (Loyalty points awarded) → Tạo Mã vận đơn (Shipping label generated). Bất kỳ mắc xích nào trong số này cũng có thể đứt. Mạng có thể rớt. Database có thể sập. Một cái cổng thanh toán (payment gateway) của bên thứ ba có thể bị timeout. ...

Điều kiện tiên quyết: Đây là Phần 7 của Khóa Học System Design. Bạn nên tham khảo lại Phần 6: Khóa Phân Tán để nắm vững các nguyên lý đồng bộ hóa tài nguyên và kiểm soát truy cập song song. Answer-first: Trong các hệ thống AI-Native và microservices năm 2026, tính kháng lặp (Idempotency) trong thiết kế API đảm bảo rằng việc gửi lại cùng một yêu cầu nhiều lần (retrying an identical request kèm theo cùng một Idempotency-Key) sẽ không tạo ra bất kỳ tác dụng phụ bổ sung nào (additional side effects) so với lần thực thi thành công đầu tiên. Đây là yêu cầu bắt buộc đối với các hệ thống thanh toán (Payment APIs) — nơi gián đoạn kết nối mạng thường khiến client gửi lại yêu cầu và có rủi ro gây ra lỗi trừ tiền trùng lặp (double charge). ...

← Bài trước | Series hub | Tiếp theo → Chương 7: Củng Cố Nền Tảng Thanh Toán Bằng Idempotent APIs Trong thế giới E-commerce hay Fintech, cơn ác mộng kinh hoàng nhất không phải là chuyện sập hệ thống, mà là trừ tiền một khách hàng tới hai lần cho cùng một hóa đơn. Cớ sự thường bắt nguồn từ mạng lag, do khách hàng sốt ruột ấn “Pay” (Thanh toán) lặp đi lặp lại, hoặc do thuật toán retry (thử lại) dập máy móc của các hệ thống tự động, nhất là các Agentic workflows trong năm 2026 với cơ chế auto-retry điên cuồng. ...