Một khách hàng xác nhận thanh toán trên website. Cổng thanh toán đã nhận yêu cầu, nhưng kết nối ngắt trước khi ứng dụng nhận phản hồi. Nếu ứng dụng gửi lại như một giao dịch mới, khách hàng có thể bị ghi nhận hai lần. Lỗi tương tự xảy ra khi webhook được gửi lại hoặc tác vụ nền khởi động sau timeout.

Retry giải quyết khả năng phục hồi. Idempotency bảo đảm nhiều lần xử lý cùng một ý định không tạo nhiều tác động. Hai cơ chế này phải được thiết kế cùng nhau, đặc biệt với các bước gửi email, tạo hóa đơn, cập nhật CRM, trừ tồn kho hoặc gọi hệ thống bên thứ ba.

Điêu khắc nhiều lớp hội tụ vào một lõi xử lý duy nhất

Retry chỉ phù hợp với một số loại lỗi

Không phải lỗi nào cũng nên thử lại. HTTP 429, timeout mạng hoặc lỗi 503 thường có tính tạm thời. Ngược lại, thiếu mã khách hàng, không đủ quyền, báo giá hết hiệu lực hoặc hết tồn kho là lỗi cần sửa đầu vào hay xin quyết định mới.

Chính sách retry cần ghi rõ số lần tối đa, khoảng chờ và điều kiện dừng. Khoảng chờ nên tăng dần, kèm độ lệch nhỏ để nhiều tác vụ không đồng loạt gọi lại dịch vụ vừa phục hồi. Tổng thời gian cũng phải phù hợp nghiệp vụ. Một yêu cầu đặt lịch được thử lại sau hai ngày vẫn là sai.

Các vòng vật liệu tách nhánh giữa lỗi tạm thời và lỗi nghiệp vụ

Khóa idempotency phải đại diện cho ý định kinh doanh

Khóa chống trùng không được tạo mới mỗi lần retry, nếu không hệ thống đích vẫn xem đó là yêu cầu độc lập. Khóa cần gắn với hành động cần hoàn thành, chẳng hạn order_id + payment_attempt, invoice_id + send_version, hoặc ID sự kiện nguồn.

Phạm vi khóa cũng cần đủ hẹp. Chỉ dùng customer_id sẽ chặn các báo giá hợp lệ về sau, còn UUID mới ở từng bước không ngăn được bản sao. Đặc tả API cần ghi khóa, thời gian lưu và phản hồi khi cùng khóa nhưng payload khác nhau. Xem cách chốt đặc tả API trước khi tích hợp.

Quy trình xử lý một tác vụ có thể được gửi lại

  1. Bước 1: Nhận yêu cầu và kiểm tra khóa

    Dịch vụ nhận khóa idempotency, xác thực đầu vào rồi tìm bản ghi tương ứng. Nếu khóa đã hoàn tất với cùng payload, dịch vụ trả lại kết quả cũ mà không thực hiện tác động lần nữa.

  2. Bước 2: Giữ quyền xử lý

    Nếu chưa có bản ghi, dịch vụ tạo trạng thái processing bằng thao tác ghi có điều kiện hoặc ràng buộc duy nhất trong cơ sở dữ liệu. Hai worker nhận cùng sự kiện sẽ không cùng giành được quyền xử lý.

  3. Bước 3: Thực hiện tác động và lưu kết quả

    Dịch vụ gọi hệ thống đích, sau đó lưu mã kết quả, thời điểm và trạng thái succeeded hoặc failed. Dữ liệu này giúp lần gọi sau biết nên trả kết quả cũ, thử lại hay chuyển sang kiểm tra thủ công.

  4. Bước 4: Xử lý kết quả không rõ ràng

    Nếu kết nối đứt sau khi hệ thống đích có thể đã thực hiện tác động, dịch vụ không mặc định rằng thao tác thất bại. Nó tra cứu theo mã tham chiếu, chờ webhook xác nhận hoặc đưa sự kiện vào hàng chờ ngoại lệ.

Cấu trúc điêu khắc bốn lớp thể hiện tiếp nhận khóa thực hiện và xác nhận

Trạng thái cần rõ hơn hai giá trị thành công và thất bại

Một cột boolean không đủ cho quy trình phân tán. Đội ngũ thường cần phân biệt received, processing, succeeded, retryable_failed, permanent_failed và unknown. Mỗi trạng thái phải có điều kiện vào, điều kiện ra và chủ thể có quyền chuyển.

Với trạng thái unknown, ứng dụng chưa biết hệ thống đích đã xử lý hay chưa. Gọi lại ngay có thể tạo bản sao, còn đánh dấu thất bại có thể bỏ sót giao dịch thành công. Hãy đối soát qua API tra cứu, webhook hoặc màn hình nghiệp vụ. Xem cách thiết kế trạng thái công việc trước khi tự động hóa.

Ranh giới giữa hệ thống và người phụ trách

Phân công khi quy trình gặp lỗi

Hệ thống tự xử lý

  • Thử lại lỗi nằm trong danh sách cho phép với khoảng chờ đã cấu hình.
  • Trả lại kết quả đã lưu khi nhận cùng khóa và cùng payload.
  • Chặn xử lý đồng thời bằng ràng buộc duy nhất hoặc khóa giao dịch.
  • Ghi mã tham chiếu, trạng thái, lần thử và nguyên nhân lỗi.

Người phụ trách xác nhận

  • Xử lý trường hợp cùng khóa nhưng payload khác nhau.
  • Đối soát trạng thái unknown với hệ thống đích.
  • Quyết định gửi lại hành động có tác động tài chính hoặc liên lạc khách hàng.
  • Mở lại tác vụ đã vượt số lần thử hoặc thời hạn nghiệp vụ.

Cảnh báo cần có khóa idempotency, tác vụ nguồn, số lần thử, phản hồi gần nhất, mã tham chiếu hệ thống đích và hành động được phép. Tham khảo thiết kế hàng chờ ngoại lệ khi AI không xử lý được.

Một lõi bị cô lập trong khung kiểm soát biểu đạt trường hợp cần người xác nhận

Test case phải mô phỏng lỗi ở đúng thời điểm

Test đường đi thành công chưa chứng minh cơ chế chống trùng hoạt động. Hãy gửi hai yêu cầu đồng thời với cùng khóa, gửi lại sau khi hoàn tất, rồi gửi cùng khóa với payload khác. Tiếp theo, ngắt kết nối trước khi hệ thống đích nhận yêu cầu và sau khi hệ thống đích xử lý. Hai thời điểm dẫn đến quyết định retry khác nhau.

Kiểm tra thêm worker khởi động lại khi đang xử lý, webhook sai thứ tự, khóa hết hạn và tác vụ cũ được phát lại. Với thành phần AI, bộ test hồi quy cần giữ đầu vào, hành động dự kiến và điều kiện chuyển cho người. Xem cách xây bộ test hồi quy cho quy trình có AI.

Retry tốt không có nghĩa là thử lại thật nhiều. Hệ thống cần biết yêu cầu nào được phép lặp, tác động nào chỉ xảy ra một lần và khi nào phải dừng để người phụ trách kiểm tra.