Phân biệt lỗi tạm thời và lỗi cần sửa
Lỗi mạng, timeout hoặc giới hạn tốc độ có thể tạm thời; dữ liệu thiếu trường bắt buộc, quyền bị thu hồi hoặc cấu hình sai thường không tự hết khi chạy lại. Đừng retry mọi lỗi giống nhau. Ghi lại mã lỗi, bước thất bại và một mã công việc để người vận hành hiểu chuyện gì xảy ra.
Retry có giới hạn và khoảng nghỉ
Với lỗi tạm thời, dùng số lần thử lại hữu hạn và khoảng nghỉ tăng dần nếu nền tảng hỗ trợ. Tôn trọng thông tin retry-after của dịch vụ khi có. Đặt tổng thời gian và giới hạn chi phí để một công việc không lặp vô tận. Với lỗi xác thực hoặc dữ liệu không hợp lệ, dừng và yêu cầu sửa cấu hình thay vì tiếp tục gọi API.
Chống trùng lặp bằng mã idempotency
Một trigger có thể phát lại sau timeout dù bước trước đã thành công. Tạo mã công việc ổn định từ nguồn sự kiện hoặc ID bản ghi, lưu trạng thái xử lý và kiểm tra trước khi tạo tác dụng phụ. Nếu dịch vụ hỗ trợ idempotency key, dùng nó. Nếu không, thiết kế thao tác kiểm tra-tồn-tại và ghi trạng thái cẩn thận; chỉ kiểm tra ở cuối luồng thường không đủ để ngăn hai lần chạy đồng thời.
Tách bước tạo bản nháp khỏi bước xuất bản
Với bài viết, tin nhắn hoặc cập nhật dữ liệu quan trọng, hãy lưu bản nháp trước, chạy kiểm tra chất lượng rồi chờ phê duyệt. Chỉ bước cuối mới được quyền xuất bản và cần ghi nhận ai đã duyệt phiên bản nào. Nếu nội dung thay đổi sau khi duyệt, yêu cầu duyệt lại.
Hàng chờ ngoại lệ và khôi phục
Khi hết số lần thử, chuyển công việc sang trạng thái NEEDS_REVIEW hoặc FAILED_REVIEW, lưu thông tin chẩn đoán không nhạy cảm và cung cấp thao tác chạy lại có kiểm soát. Người xử lý cần biết chạy lại từ bước nào, bước nào đã thành công và liệu có tác dụng phụ đã xảy ra hay chưa.
Kiểm thử các tình huống xấu
Thử timeout sau khi API đã nhận yêu cầu, hai trigger cùng lúc, giới hạn tốc độ, token hết hạn, đầu vào thiếu và lỗi ở bước xuất bản. Xác nhận không tạo bản ghi trùng, không gửi trùng thông điệp và không mất trạng thái. Định nghĩa cách dừng khẩn cấp trước khi đưa vào sử dụng.