Retry giúp workflow tự động hóa vượt qua lỗi tạm thời như timeout, giới hạn tốc độ hoặc dịch vụ đích gián đoạn. Nhưng retry không giới hạn, không có khoảng chờ và không phân biệt lỗi có thể thử lại sẽ biến sự cố nhỏ thành retry storm: nhiều worker cùng gửi lại yêu cầu và làm hệ thống đích quá tải hơn. Retry trong workflow là gì? Retry là cơ chế thực hiện lại thao tác sau khi lần thử trước thất bại. Cơ chế này phù hợp với lỗi có khả năng tự biến mất như timeout mạng, 429 hoặc 5xx. Retry không phải cách sửa lỗi dữ liệu, lỗi xác thực hoặc lỗi logic nghiệp vụ. Một policy tốt phải nêu rõ lỗi nào được thử lại, số lần tối đa, khoảng chờ và điểm dừng sau lần thất bại cuối. Exponential backoff và jitter khác nhau thế nào? Exponential backoff làm khoảng chờ tăng dần, ví dụ 1, 2, 4 rồi 8 giây, nhưng luôn có trần tối đa. Jitter là độ trễ ngẫu nhiên nhỏ giúp các client không đồng bộ retry cùng lúc. Nếu hàng nghìn worker cùng retry sau đúng 8 giây, hệ thống đích sẽ nhận một đợt tải mới; jitter dàn các lần thử ra trong một khoảng thời gian. AWS SDK dùng exponential backoff với jitter ở chế độ retry tiêu chuẩn; Microsoft Azure cũng khuyến nghị mô hình này cho tác vụ nền. Khi nào nên retry và khi nào phải dừng? Nên retry khi lỗi có tính tạm thời và thao tác an toàn để lặp, như timeout, 429 hoặc 503. Nếu dịch vụ trả Retry-After, hãy tôn trọng giá trị đó trong giới hạn policy. Không nên retry lỗi payload sai, token hết hạn, quyền không hợp lệ hoặc vi phạm nghiệp vụ. Với thao tác tạo đơn, trừ tiền hay gửi thông báo, retry phải đi kèm idempotency key. Xem bài https://chatgptskill.xyz/blog/idempotency-chong-chay-trung-workflow-tu-dong-hoa. Thiết kế retry policy theo từng lớp Phân loại mã lỗi thành retry được, không retry và cần người duyệt. Đặt cả max attempts và max elapsed time; chỉ đặt số lần thử là chưa đủ. Dùng công thức khái niệm delay = min(cap, base × 2^attempt) + jitter, với giá trị cụ thể căn cứ SLA và giới hạn dịch vụ. Ngoài giới hạn từng request, cần retry budget ở cấp service để ngăn hàng nghìn request cùng retry làm quá tải dependency. Quy trình triển khai an toàn 1. Ghi nhận lỗi gốc, attempt count, thời điểm và trace ID. 2. Kiểm tra mã lỗi và quyết định có retry. 3. Tính backoff, áp dụng jitter và tôn trọng Retry-After. 4. Kiểm tra idempotency trước thao tác có tác động. 5. Dừng khi đạt max attempts, max elapsed time hoặc hết retry budget. 6. Đưa sự kiện không thể tiếp tục vào DLQ cùng metadata. 7. Theo dõi tỷ lệ thành công sau retry, không chỉ đếm số lần thử. Retry cho tác vụ tương tác và tác vụ nền Tác vụ tương tác cần phản hồi nhanh nên fail fast, chỉ retry ít lần hoặc theo Retry-After. Tác vụ nền có thể chờ lâu hơn, dùng exponential backoff với jitter và tiếp tục qua worker khác; vẫn phải có visibility timeout, lease và giới hạn tổng thời gian. Đo lường và cảnh báo Theo dõi tỷ lệ thành công ngay lần đầu, tỷ lệ thành công sau retry, số lần retry trung bình, p95 thời gian hoàn tất, số sự kiện chạm max attempts, retry budget còn lại và số sự kiện vào DLQ. Đừng cảnh báo chỉ vì số lần retry tăng; chú ý tỷ lệ thành công sau retry giảm, độ trễ tăng, budget cạn hoặc DLQ tăng nhanh. Tham khảo https://chatgptskill.xyz/blog/dead-letter-queue-xu-ly-loi-workflow-tu-dong-hoa và https://chatgptskill.xyz/blog/thiet-ke-dashboard-kpi-workflow-tu-dong-hoa. Các lỗi thiết kế thường gặp Retry vô hạn; khoảng chờ cố định; có backoff nhưng không jitter và cap; retry mọi mã lỗi; mất idempotency key khi retry; log thiếu attempt count; không có retry budget; không kiểm thử khi hàng nghìn worker cùng thất bại. Checklist trước production Đã lập bảng lỗi retry được và không retry; có max attempts, max elapsed time, backoff, jitter và cap; có retry budget; có idempotency; tôn trọng Retry-After; có DLQ sau lần thử cuối; log đủ error code, trace ID và thời gian chờ; dashboard phân biệt lỗi lần đầu, lỗi sau retry và lỗi vào DLQ; đã kiểm thử retry storm, timeout kéo dài, 429, 5xx và trạng thái không chắc chắn. Câu hỏi thường gặp Exponential backoff có đủ chống retry storm không? Chưa đủ; cần jitter, cap, giới hạn lần thử và retry budget. Có nên retry mọi lỗi HTTP 5xx không? Không máy móc; cần xem hợp đồng API, tính an toàn khi lặp và Retry-After. Jitter tính thế nào? Dùng độ trễ ngẫu nhiên trong giới hạn backoff; mục tiêu là tránh client retry cùng thời điểm và vẫn giữ trần độ trễ. Khi nào chuyển lỗi sang DLQ? Khi lỗi không retry được, chạm giới hạn, hết budget hoặc cần điều tra trạng thái không chắc chắn. Kết luận Retry tốt không có nghĩa là thử lại nhiều lần. Đó là policy có phân loại lỗi, exponential backoff, jitter, giới hạn, idempotency và điểm dừng rõ ràng. Kết hợp retry budget với DLQ và dashboard giúp workflow tự phục hồi mà không khuếch đại sự cố thành retry storm.