Khi gửi lệnh tạo đơn rồi hết thời gian chờ, ứng dụng có thể không biết máy chủ đã xử lý đến đâu. Gửi lại ngay có thể tạo đơn thứ hai; báo thất bại chắc chắn cũng có thể khiến người dùng xử lý sai.
Timeout là thiếu phản hồi, không phải bằng chứng chưa ghi
Kết nối có thể bị ngắt sau khi hệ thống đích đã nhận và xử lý. Tách lỗi trước khi gửi, lỗi nhận phản hồi và lỗi nghiệp vụ đã có trả lời. Nếu không phân biệt được, dùng trạng thái chưa xác định và cấm giao diện khẳng định đơn không tồn tại.
Chuẩn bị khóa trước lần gọi đầu
Tạo mã yêu cầu ổn định gắn với một ý định nghiệp vụ. Nếu provider hỗ trợ idempotency, dùng đúng phạm vi và thời hạn theo tài liệu; không tạo khóa mới cho mỗi lần retry cùng một ý định. Nếu không có cơ chế này, cần tra cứu bằng khóa nghiệp vụ hoặc quy trình đối soát trước khi gửi lại.
Ví dụ giả định: tạo đơn giao hàng
Một nhân viên giả định nhấn tạo đơn rồi thấy màn hình chờ quá lâu. Hệ thống giữ mã yêu cầu và thông báo đang xác minh. Khi tra cứu thấy đơn ở hệ thống đích, ứng dụng liên kết đơn đó thay vì tạo mới. Nếu không tìm được, người phụ trách kiểm tra độ trễ tìm kiếm và log trước khi cho phép thử lại.
| Bằng chứng | Trạng thái | Thao tác |
|---|---|---|
| Có phản hồi thành công | Đã xác nhận | Liên kết kết quả |
| Timeout sau khi gửi | Chưa xác định | Tra cứu, không tạo mới |
| Không có kết quả sau đối soát | Chờ quyết định | Retry theo hợp đồng |
Tránh biến nút retry thành thao tác nghiệp vụ mới
Giao diện cần phân biệt thử lại cùng yêu cầu với tạo yêu cầu mới. Giữ dữ liệu người dùng đã nhập và mã tham chiếu. Nếu người dùng sửa nội dung sau timeout, phải xác minh yêu cầu cũ trước, vì một ý định mới không hủy được tác động có thể đã xảy ra của ý định trước.
Nghiệm thu cả phản hồi bị mất
Trong môi trường thử được phép, mô phỏng máy chủ đã xử lý nhưng client không nhận được phản hồi. Kiểm tra chỉ có một kết quả nghiệp vụ, trạng thái được cập nhật khi đối chiếu xong và người vận hành thấy được yêu cầu còn treo. Không dùng số lần gọi API làm số đơn đã tạo.
Đặt trách nhiệm cho phần chưa xác định
Mỗi yêu cầu treo cần người nhận, thời hạn đối chiếu và bằng chứng kết luận. Tự động hóa có thể giảm thao tác, nhưng quyết định gửi lại khi thiếu khả năng kiểm tra vẫn là rủi ro nghiệp vụ cần owner chấp nhận, không phải một thông số retry đơn thuần.
Chuẩn bị gì khi trao đổi phạm vi triển khai?
Một yêu cầu timeout đã che dữ liệu cùng khóa tham chiếu là điểm bắt đầu để trao đổi luồng xử lý đơn trong phần mềm. Cần xác nhận khả năng tra cứu kết quả của provider trước khi quyết định cho retry tự động.
Chuẩn bị bộ test giả lập API không ổn định; công cụ soạn yêu cầu không thay thế việc xác nhận hành vi trên hệ thống thực tế.
Nguồn kiểm chứng và giới hạn áp dụng
Tài liệu chính thức: Stripe hỗ trợ idempotency theo chính sách của API. Đối chiếu ngày 12/10/2026. Các bảng và quy trình trong bài là đề xuất biên tập; ví dụ giả định không phải dự án hay kết quả khách hàng Onter.
