Dead-Letter Queue Mengisolasi Poison Message Tanpa Menghambat Progres

Message consumer biasanya memperlakukan kegagalan sebagai kondisi sementara pada percobaan awal. Database mungkin tidak tersedia, remote service dapat timeout, atau worker dapat restart di antara penerimaan dan acknowledgment message. Retry tepat digunakan ketika percobaan berikutnya memiliki peluang masuk akal untuk berhasil.

Sebagian message gagal karena sebab yang berbeda. Payload-nya rusak, entity yang dirujuk tidak akan pernah memenuhi kondisi wajib, atau consumer memiliki defect deterministik yang dipicu input tersebut. Delivery berulang kemudian menghabiskan kapasitas tanpa membawa message lebih dekat ke penyelesaian. Dead-letter queue memberi kegagalan itu tujuan terpisah setelah kebijakan retry normal habis.

Redelivery tanpa batas mengubah satu message buruk menjadi beban berkelanjutan

Bayangkan consumer menerima message, gagal, lalu segera mengembalikannya ke queue yang sama:

receive -> fail -> requeue -> receive -> fail -> requeue

Loop tersebut dapat menghabiskan CPU, I/O broker, bandwidth jaringan, volume log, dan downstream call untuk satu item. Pada aliran dengan ordering ketat, poison message juga dapat menahan message berikutnya dalam ordered stream yang sama.

Batas retry memberi batas pada pekerjaan ini:

attempt 1 -> fail
attempt 2 -> fail
attempt 3 -> fail
move to dead-letter queue

Transisi ke dead-letter tidak memperbaiki message. Mekanisme ini memisahkan kegagalan berulang dari jalur pemrosesan utama agar pekerjaan lain yang memenuhi syarat dapat terus berjalan.

Kebijakan retry berada sebelum kebijakan dead-letter

Dead-letter queue tidak seharusnya menjadi respons pertama untuk setiap error. Kegagalan sementara sering pulih, sedangkan kegagalan deterministik biasanya tidak mendapat manfaat dari banyak percobaan yang identik.

Kebijakan retry yang berguna mempertimbangkan kelas error, jumlah attempt, waktu yang telah berlalu, dan deadline message bila ada. Backoff dan jitter dapat mencegah gangguan dependency sementara menghasilkan traffic retry yang tersinkronisasi. Validation error permanen dapat langsung diarahkan ke dead-letter ketika aplikasi dapat mengklasifikasikannya secara andal.

Broker dan consumer memerlukan satu definisi attempt yang konsisten. Jika broker menaikkan delivery count sementara middleware aplikasi memiliki retry loop terpisah, jumlah eksekusi efektif dapat jauh lebih besar daripada nilai konfigurasi yang terlihat.

broker deliveries x local attempts = possible executions

Perkalian itu penting untuk handler mahal dan operasi yang memiliki external side effect.

Record dead-letter memerlukan konteks yang cukup untuk diagnosis

Dead-letter queue yang hanya menyimpan payload asli sering meninggalkan terlalu sedikit bukti bagi operator. Recovery lebih aman ketika record membawa konteks pemrosesan bersama message.

Metadata yang berguna dapat mencakup:

original destination
message identifier
first failure time
last failure time
attempt count
consumer version
error class
correlation identifier

Payload sensitif dan exception text tetap tunduk pada aturan penanganan data yang sama dengan sistem utama. Memindahkan message ke queue lain bukan alasan untuk memperluas retention atau mengekspos secret dalam metadata diagnostik.

Payload asli sebaiknya tetap utuh kecuali sistem memiliki format envelope yang disengaja. Mengubah input gagal selama transfer membuat reproduksi berikutnya lebih sulit dan dapat menghapus byte persis yang memicu kegagalan.

Dead-letter queue bukan arsip

Penyimpanan dead-letter memerlukan kebijakan retention eksplisit. Menyimpan setiap message gagal selamanya menciptakan data store tanpa batas, sedangkan menghapus kegagalan terlalu cepat dapat menghilangkan bukti yang dibutuhkan untuk recovery.

Retention perlu disesuaikan dengan waktu respons operasional, persyaratan kepatuhan, sensitivitas payload, dan volume kegagalan yang diperkirakan. Alert kapasitas penting karena lonjakan traffic dead-letter dapat memenuhi storage saat terjadi defect consumer yang luas.

Usia sama pentingnya dengan depth. Sepuluh kegagalan baru saat deployment memiliki arti operasional berbeda dari sepuluh message yang tidak disentuh selama beberapa bulan.

Replay harus menjadi transisi state yang terkontrol

Setelah defect diperbaiki atau data yang hilang dipulihkan, operator mungkin ingin melakukan replay terhadap message di dead-letter. Menyalin seluruh queue kembali ke tujuan utama dalam satu tindakan dapat mengulang insiden awal dengan kecepatan penuh.

Jalur replay yang lebih aman mendukung seleksi, rate limit, dan observasi:

select eligible failures
        |
        v
replay at bounded rate
        |
        v
normal consumer path

Seleksi dapat menggunakan kelas error, rentang waktu, versi consumer, tenant, atau message identifier. Kriterianya sebaiknya berdasarkan field yang stabil dan dapat diaudit.

Replay juga memerlukan aturan disposition. Message yang kembali gagal tidak boleh memantul tanpa batas antara primary queue dan dead-letter queue dengan history yang selalu di-reset. Mempertahankan original failure identifier atau cumulative attempt history membuat siklus recovery berulang tetap terlihat.

Idempotency tetap diperlukan saat recovery

Message yang masuk dead-letter mungkin telah menghasilkan sebagian efek yang dimaksud sebelum handler gagal. Sebagai contoh, consumer dapat menulis ke satu sistem lalu gagal sebelum mencatat completion di sistem lain.

Replay message tersebut dapat mengulang side effect sebelumnya. Dead-letter queue tidak menyediakan exactly-once execution dan tidak membuktikan bahwa attempt terdahulu bebas efek.

Handler yang dapat di-retry atau di-replay memerlukan strategi idempotency yang sesuai dengan efeknya. Mekanismenya dapat berupa unique operation key, inbox table, conditional write, atau mekanisme deduplication durable lain. Pilihan yang tepat bergantung pada resource yang menerima efek.

Ordering mengubah pilihan yang tersedia

Ordered stream membuat penanganan poison message lebih sulit. Melewati satu message dapat membuat message berikutnya berjalan pada state yang mengasumsikan event yang dilewati sudah diterapkan.

Untuk workload dengan ordering ketat per key, sistem mungkin perlu menghentikan hanya key atau partition yang terdampak, bukan memindahkan satu message ke dead-letter lalu melanjutkan secara buta. Desain lain dapat mengarahkan key yang gagal ke quarantine sementara key independen tetap berjalan.

Liveness dan ordering merupakan requirement yang berbeda. Kebijakan dead-letter yang meningkatkan throughput tetap dapat melanggar semantik aplikasi jika message berikutnya bergantung pada message yang gagal.

Monitoring perlu memperlakukan traffic dead-letter sebagai sinyal kegagalan

Primary queue yang sehat dapat menyembunyikan dead-letter queue yang terus bertambah. Monitoring karena itu perlu mencakup kedua jalur.

Sinyal yang berguna meliputi dead-letter rate, queue depth, usia message tertua, kegagalan per kelas error, kegagalan per versi consumer, replay rate, dan proporsi message replay yang kembali gagal.

Lonjakan setelah deployment sering mengarah pada masalah kompatibilitas atau regresi handler. Konsentrasi pada satu tenant atau tipe payload dapat menunjukkan source data yang buruk. Kenaikan perlahan dapat menandakan schema drift atau dependency yang perilaku error handling-nya berubah.

Alert sebaiknya berfokus pada kondisi yang dapat ditindaklanjuti, bukan setiap message gagal secara individual. Sistem bervolume tinggi dapat menghasilkan input yang sesekali tidak dapat diproses tanpa memerlukan incident untuk masing-masing item.

Jalur kegagalan memerlukan disiplin rekayasa yang sama dengan jalur sukses

Penanganan dead-letter adalah bagian dari semantik message processing, bukan sekadar checkbox broker. Batas retry, klasifikasi kegagalan, metadata, retention, replay, idempotency, ordering, dan monitoring menentukan apakah mekanisme benar-benar membatasi poison message atau hanya memindahkan kebingungan ke queue lain.

Jalur dead-letter yang terdefinisi baik memberi biaya terbatas pada kegagalan berulang. Traffic sehat mempertahankan kapasitas, input gagal tetap dapat diperiksa, dan recovery dapat berjalan secara terarah tanpa bergantung pada redelivery tanpa akhir.