Khi xây dựng các API trong hệ thống Microservices, tại sao việc thiết kế Idempotency (Tính bất biến của thao tác) lại là yêu cầu bắt buộc đối với các API thực thi lệnh ghi dữ liệu (POST/PUT)?

Question

Accepted Answer

Bản chất vấn đề
Trong mạng máy tính phân tán, các lỗi mạng (network timeout, packet loss) là điều không thể tránh khỏi. Khi một Client gửi request thanh toán đến Microservices nhưng bị timeout ở tầng mạng, Client sẽ có xu hướng retry lại request đó. Nếu API không có cơ chế Idempotency, hệ thống sẽ thực hiện giao dịch trừ tiền nhiều lần.
Định nghĩa Idempotency
Một thao tác được gọi là idempotent nếu thực hiện nó nhiều lần mang lại kết quả giống hệt như thực hiện nó đúng một lần.

Phép toán GET, PUT, DELETE về mặt bản chất lý thuyết là idempotent.
Phép toán POST mặc định không idempotent, do đó lập trình viên phải chủ động thiết kế cơ chế bảo vệ.

Giải pháp kỹ thuật thực tế

Idempotency Key: Client sinh ra một mã định danh duy nhất (UUID) cho mỗi hành động (ví dụ gửi kèm header X-Idempotency-Key).
Distributed Cache / Database Lock: Service nhận request sẽ kiểm tra xem Idempotency Key này đã được xử lý trước đó chưa (lưu trong Redis với thời gian sống TTL nhất định).
Nếu tồn tại và đang xử lý: Trả về kết quả cũ hoặc mã lỗi đang xử lý.
Nếu chưa tồn tại: Lưu key vào Redis với trạng thái PROCESSING, thực hiện nghiệp vụ, sau đó cập nhật trạng thái SUCCESS kèm kết quả.

Lưu ý kinh nghiệm thực chiến cho Junior
Luôn bàn bạc với Frontend/Mobile developer để thống nhất cơ chế truyền Idempotency-Key từ phía client cho các API quan trọng như tạo đơn hàng, thanh toán, đặt vé.

Khi xây dựng các API trong hệ thống Microservices, tại sao việc thiết kế Idempotency (Tính bất biến của thao tác) lại là yêu cầu bắt buộc đối với các API thực thi lệnh ghi dữ liệu (POST/PUT)?

Bản chất vấn đề

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi microservices liên quan cùng chủ đề