Workflow xử lý yêu cầu từ email đến ticket: thiết kế thế nào để không bỏ sót?
Thiết kế workflow email-to-ticket có idempotency, hàng đợi, retry, DLQ, SLA, cảnh báo và đối soát để không bỏ sót yêu cầu hoặc tạo ticket trùng.
Email-to-ticket không nên được thiết kế như một chuỗi bước đơn giản: đọc email, gọi API rồi đánh dấu đã xử lý. Để không bỏ sót, hệ thống phải ghi nhận email trước, đưa yêu cầu vào hàng đợi bền vững, tạo ticket theo cơ chế idempotent và chỉ xác nhận hoàn tất khi đã lưu được ticketId. Mọi lỗi tạm thời cần được retry có giới hạn; lỗi kéo dài phải chuyển sang dead-letter queue (DLQ), cảnh báo cho người vận hành và có đường chạy lại an toàn.
Điểm quyết định là tách tiếp nhận khỏi xử lý. Khi hệ thống ticket chậm hoặc workflow bị khởi động lại, email vẫn nằm trong kho tiếp nhận và hàng đợi, thay vì biến mất sau khi bị đánh dấu đã đọc. Một job đối soát định kỳ tiếp tục tìm email chưa có ticket để khép kín những khoảng trống mà giám sát thời gian thực có thể bỏ qua.
Rủi ro
Vì sao email đã đến nhưng ticket vẫn bị bỏ sót?
Phần lớn sự cố nằm ở ranh giới giữa các hệ thống, không nằm ở hộp thư.
Các lỗi phổ biến gồm webhook không đến, token truy cập hết hạn, worker dừng giữa chừng, API ticket trả lỗi hoặc timeout, mapping sai mailbox, và workflow đánh dấu email đã xử lý trước khi ticket thực sự được tạo. Retry thiếu kiểm soát lại gây rủi ro ngược: một email tạo nhiều ticket.
Không nên dùng trạng thái read/unread làm bằng chứng duy nhất. Người dùng, rule trong mailbox hoặc ứng dụng khác đều có thể thay đổi trạng thái này. Hãy lưu một bản ghi tiếp nhận riêng với định danh từ nhà cung cấp email, Message-ID, mailbox, thời điểm nhận, checksum nội dung và trạng thái xử lý. Theo RFC 5322, Message-ID là trường nhận dạng của thư; tuy nhiên trong triển khai thực tế nên kết hợp nó với mailbox hoặc immutable provider ID vì email chuyển tiếp, nhập lại hoặc hệ thống gửi lỗi có thể làm định danh không hoàn hảo.
