Đây là bài 1 trong phần 3 của chuỗi demo “System Design: Giải thích những quyết định kiến trúc”. Đặt giả định, chọn ranh giới và đánh giá tradeoff khi thiết kế một nền tảng học trực tuyến. Bài viết dùng ví dụ và dữ liệu giả để minh họa; hãy thử trên môi trường riêng trước khi áp dụng vào dự án.
Mục tiêu cụ thể
API cần hợp đồng đầu vào, đầu ra và lỗi. Idempotency giúp client gửi lại thao tác mà không gây tác dụng phụ trùng trong điều kiện đã xác định.
Hiểu vấn đề trước khi dùng công cụ
Chương này tập trung vào một quyết định cụ thể: Thiết kế hợp đồng đăng ký khóa học có thể retry sau timeout; mô tả trường hợp hai request đến cùng lúc. Đừng bắt đầu bằng cách chép nguyên ví dụ. Hãy chỉ ra thành phần nào là dữ liệu, thành phần nào là quy tắc và đâu là kết quả quan sát được. Một giải pháp đúng với dữ liệu mẫu vẫn có thể sai khi đầu vào rỗng, kích thước lớn hơn hoặc có hai thao tác xảy ra gần nhau.
Ví dụ tối thiểu
POST /enrollments
Idempotency-Key: demo-request-123
Body: {"course_id": 42}
Server lưu khóa, fingerprint của request và kết quả.
Cùng khóa nhưng payload khác cần bị từ chối.Giới hạn cần hiểu
Chỉ thêm header không tự tạo idempotency. Cần lưu trạng thái, xử lý request đồng thời và chính sách hết hạn.
Câu hỏi để tự giải thích
- Bạn sẽ giải thích api và idempotency cho người mới bằng ví dụ nào?
- Phần nào của ví dụ là giả định, phần nào cần kiểm tra bằng thực nghiệm?
- Nếu bỏ một điều kiện quan trọng, kết quả sẽ sai ở đâu?
Kết quả cần đạt
- Request lặp có kết quả nhất quán
- Payload khác không dùng chung khóa
- Có chính sách lưu và hết hạn khóa
Trước khi chuyển bài, hãy viết một đoạn giải thích bằng lời của bạn và chỉ ra ít nhất một trường hợp không nên áp dụng máy móc ví dụ này.