Api Design

Mọi API hướng ra công chúng (public-facing) trong Nền tảng Composable Commerce đều bắt đầu từ một file .proto. Phần code — bao gồm các hàm handler gRPC viết bằng Go, TypeScript SDK, các route HTTP, kiểm tra tính hợp lệ của request (request validation), các mã lỗi — tất cả đều được tự động generate ra từ bản hợp đồng (contract) đó. Bài viết này sẽ ghi chép lại những quy ước đằng sau để hệ thống đó vận hành mượt mà. ...

Đ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. ...