Đưa công việc lỗi vào một hàng chờ riêng mới chỉ giữ được dấu vết. Giá trị của dead-letter queue nằm ở việc biết công việc nào được sửa, công việc nào phải bỏ và khi nào được phép phát lại.
Đừng xem mọi thông điệp lỗi là cùng một loại
Lỗi dữ liệu thiếu, lỗi quyền, dịch vụ đích tạm ngừng và lỗi mã nguồn cần cách xử lý khác nhau. Gom theo nguyên nhân có bằng chứng, phiên bản handler và khoảng thời gian xảy ra. Số lượng trong DLQ không cho biết số khách hàng bị ảnh hưởng nếu một công việc đã xuất hiện nhiều lần.
Phiếu quyết định trước khi redrive
Ghi mã thông điệp, khóa nghiệp vụ, phiên bản payload, lần xử lý gần nhất, tác động phụ có thể đã xảy ra và người duyệt. Xác minh chính sách retention của dịch vụ thực tế; không coi DLQ là kho lưu dài hạn. Bản cần giữ cho điều tra phải được bảo quản theo quyền và thời hạn phù hợp.
Ví dụ giả định: phiếu giao hàng bị kẹt
Một nhóm giả định đã sửa lỗi đọc mã kho. Trước khi phát lại, nhóm kiểm tra phiếu giao hàng ở hệ thống đích đã tồn tại chưa. Công việc chưa có tác động có thể được thử theo mẫu nhỏ; công việc đã tạo phiếu nhưng thiếu phản hồi cần đối chiếu trước. Cả hai cùng có lỗi nhưng không được cùng một cách retry.
| Nhóm | Quyết định trước phát lại | Điểm dừng |
|---|---|---|
| Dữ liệu sai | Sửa có dấu vết và duyệt | Không rõ nguồn đúng |
| Đích đã xử lý | Đối chiếu khóa nghiệp vụ | Có nguy cơ trùng |
| Lỗi tạm thời | Canary sau khi khôi phục | Lỗi vẫn lặp |
Canary phải đo kết quả nghiệp vụ
Chọn mẫu đại diện cho từng nguyên nhân và phiên bản dữ liệu. Theo dõi số bản ghi tạo thêm, trạng thái đích và lỗi mới, không chỉ số thông điệp rời DLQ. Một thông điệp bị xóa khỏi hàng chờ chưa chứng minh nghiệp vụ hoàn tất. Giữ liên kết giữa lần lỗi và lần phát lại để có thể điều tra.
Điểm dừng và người nhận ngoại lệ
Dừng mở rộng khi phát sinh bản ghi trùng, lỗi khác mẫu hoặc thiếu quyền quan sát hệ thống đích. Người duyệt cần biết cách hủy lượt chạy, phần nào đã hoàn thành và phần nào còn chờ. Không phát lại toàn bộ chỉ vì bản sửa mã nguồn đã được triển khai.
Giữ DLQ thành một quy trình có owner
Mỗi nhóm lỗi cần người nhận và hạn đánh giá. Nếu không ai xem hàng chờ, việc tách lỗi chỉ chuyển sự cố ra khỏi màn hình chính. Chọn cơ chế cảnh báo theo tác động nghiệp vụ và thời gian tồn đọng; không đặt mục tiêu làm hàng chờ về không bằng mọi giá.
Chuẩn bị gì khi trao đổi phạm vi triển khai?
Chuẩn bị một nhóm lỗi có payload đã che dữ liệu và dấu vết ở hệ thống đích khi cần rà soát tích hợp phần mềm. Phiếu quyết định phát lại giúp phân biệt phần cần sửa mã với phần cần đối soát thủ công.
Nguồn kiểm chứng và giới hạn áp dụng
Tài liệu chính thức: Amazon SQS mô tả DLQ, maxReceiveCount và lưu ý về retention. Đối chiếu ngày 12/10/2026. Các bảng và quy trình trong bài là đề xuất biên tập; ví dụ giả định không phải dự án hay kết quả khách hàng Onter.
