Workflow nên retry bao nhiêu lần?
Không có số universal. Chọn attempt/delay theo recovery pattern của downstream, request cost, SLA và rủi ro duplicate side effect. Policy phải explicit và observable.
D2 Automation Knowledge
Retry, Backoff và Dead-Letter Workflow trong n8n
Framework reliability cho transient failure, bounded retry, terminal error, dead-letter queue và safe replay.
Biên soạn bởi: D2 Automation SystemsRà soát bởi: D2 Systems EngineeringXuất bản: 2026-08-21Cập nhật: 2026-08-21
Câu trả lời ngắn
Câu trả lời thực tế
Chỉ retry lỗi có khả năng thành công nếu thử lại sau. Giới hạn số attempt, tăng delay giữa các attempt, giữ original event + error context và đưa terminal failure vào dead-letter path có thể inspect/replay. Blind retry biến một lỗi thành load amplification; không retry lại biến lỗi network tạm thời thành mất việc.
Engineering model
Failure policy = classify error → bounded retry → backoff/jitter → terminal routing → evidence-preserving replay
01 / Design rule
Phân loại lỗi trước khi retry
429 rate limit, 5xx tạm thời và network timeout có thể transient. Invalid credential, schema validation failure và forbidden access thường cần intervention thay vì retry liên tục. Classification giúp tránh retry lãng phí và không che lỗi thật.
02 / Design rule
Backoff bảo vệ cả hai hệ thống
Retry ngay lập tức có thể làm outage/rate-limit nặng hơn. Exponential hoặc staged backoff giãn attempt theo thời gian; jitter giảm synchronized retry spike khi nhiều job fail cùng lúc.
03 / Design rule
Dead-letter là một operational state
Dead-letter record nên có đủ context để diagnose: original event reference, workflow/version, attempt count, error category và last error. Nó không chỉ là notification báo lỗi.
04 / Design rule
Replay phải tôn trọng idempotency
Replay terminal failure chỉ hữu ích khi uniqueness/state control vẫn active. Nếu không, recovery có thể tạo duplicate downstream effect dù original error đã được sửa.
Checklist triển khai
Các câu hỏi cần chốt trước khi gọi workflow là production-ready.
- Tách transient và terminal error
- Đặt max attempt
- Dùng staged/exponential backoff
- Persist terminal failure context
- Replay có kiểm soát và idempotency
FAQ
Chỉ notification lỗi có đủ không?
Không đủ với workflow quan trọng. Notification nên dẫn tới durable context và recovery action. Nếu không operator biết có lỗi nhưng không thể resume an toàn.
Tiêu chuẩn evidence
Architecture knowledge, implementation evidence và production outcome là các mức claim khác nhau.
D2 công khai các boundary này. Methodology page giải thích evidence cần có trước khi một hệ thống được mô tả là implemented, validated hoặc production-backed.
Xem methodology về evidenceCase study liên quan
Xem engineering decision được áp dụng trong các case study của D2.
Áp dụng framework