Dead Letter Queue: Cara Menangani Pesan Gagal pada Sistem Event-Driven

Dalam sistem berbasis event, sebuah pesan biasanya melewati beberapa layanan sebelum pekerjaan selesai. Misalnya, layanan pesanan mengirim event pembayaran, lalu layanan lain memperbarui stok dan mengirim notifikasi. Jika salah satu konsumen terus gagal memproses pesan, antrean dapat menumpuk dan pesan yang sama berulang kali menghambat pekerjaan berikutnya. Dead Letter Queue (DLQ) membantu mengisolasi pesan yang tidak berhasil diproses agar masalah dapat ditelusuri tanpa menghentikan seluruh alur.

Apa Itu Dead Letter Queue?

Dead Letter Queue adalah antrean khusus untuk menampung pesan yang gagal diproses setelah memenuhi aturan tertentu. Pesan biasanya dipindahkan ke DLQ setelah percobaan ulang mencapai batas, melewati masa berlaku, atau ditolak karena tidak memenuhi ketentuan. DLQ bukan tempat sampah otomatis: isinya merupakan bukti penting untuk mengetahui penyebab kegagalan dan menentukan apakah pesan aman untuk diproses kembali.

Fitur ini tersedia dalam berbagai bentuk pada broker pesan dan layanan antrean, tetapi perilaku detailnya berbeda. Ada platform yang menyediakan DLQ bawaan, sedangkan sistem lain memerlukan antrean terpisah dan logika pemindahan pesan yang dirancang sendiri. Karena itu, dokumentasi layanan yang digunakan tetap perlu menjadi acuan.

Mengapa Pesan Bisa Gagal?

Kegagalan tidak selalu berarti kode konsumen rusak. Pesan dapat berisi skema yang tidak valid, mengacu pada data yang belum tersedia, atau membutuhkan layanan eksternal yang sedang mengalami gangguan. Masalah sementara seperti timeout jaringan biasanya layak dicoba ulang. Sebaliknya, format yang salah atau nilai wajib yang hilang tidak akan pulih hanya dengan mengulang permintaan berkali-kali.

Perbedaan ini penting karena retry tanpa batas dapat membuat antrean utama terus memproses pesan yang sama. Dampaknya bisa berupa latensi yang meningkat, biaya pemrosesan lebih tinggi, dan pesan valid tertahan di belakang pesan bermasalah.

Rancang Kebijakan Retry Sebelum DLQ

DLQ paling berguna ketika aturan retry jelas. Tentukan jumlah percobaan maksimum, batas waktu pemrosesan, dan jenis kesalahan yang boleh dicoba ulang. Untuk gangguan sementara, gunakan jeda bertahap atau exponential backoff. Tambahkan jitter agar banyak konsumen tidak mengulang permintaan pada saat yang sama setelah layanan pulih.

Hindari retry langsung tanpa jeda ketika layanan eksternal sedang gagal. Pola itu dapat memperparah beban dan menciptakan lonjakan permintaan. Untuk kesalahan permanen—misalnya payload tidak dapat diparsing—pindahkan pesan ke jalur penanganan yang sesuai setelah validasi gagal, bukan terus mengulangnya.

Informasi yang Perlu Disimpan pada Pesan DLQ

Ketika pesan dipindahkan, simpan payload asli jika kebijakan privasi mengizinkan, beserta metadata yang membantu investigasi. Informasi yang berguna antara lain:

• ID pesan dan correlation ID untuk menghubungkan event dengan permintaan atau transaksi asal.
• Waktu kegagalan dan jumlah percobaan untuk melihat pola berulang dan menentukan urutan penanganan.
• Kode kesalahan dan tahap pemrosesan agar tim dapat membedakan masalah validasi, jaringan, dependensi, atau logika aplikasi.
• Versi skema dan konsumen untuk memeriksa apakah kegagalan muncul setelah perubahan aplikasi.

Jangan menyalin rahasia, token autentikasi, atau data pribadi secara sembarangan ke DLQ dan log. Terapkan kontrol akses, masa retensi, serta penyamaran data sensitif. Antrean kegagalan sering menyimpan payload yang belum berhasil melewati jalur normal, sehingga perlu dilindungi seperti penyimpanan operasional lainnya.

Alur Kerja Penanganan DLQ

Mulailah dengan memantau jumlah pesan masuk, laju pertumbuhan DLQ, umur pesan tertua, dan alasan kegagalan yang paling sering muncul. Tetapkan ambang peringatan yang sesuai dengan karakter layanan. Satu pesan gagal mungkin wajar, tetapi lonjakan mendadak atau antrean yang terus bertambah dapat menunjukkan insiden.

Ketika peringatan muncul, kelompokkan pesan berdasarkan kode kesalahan dan versi konsumen. Perbaiki penyebab utamanya terlebih dahulu, misalnya dengan memperbaiki validasi, memulihkan dependensi, atau menerapkan dukungan skema yang benar. Setelah itu, uji beberapa pesan di lingkungan terkontrol sebelum melakukan pemrosesan ulang secara massal.

Replay harus dirancang dengan hati-hati. Pastikan operasi konsumen idempoten atau memiliki mekanisme deduplikasi sehingga pengiriman ulang tidak membuat pembayaran, pesanan, atau notifikasi ganda. Pertimbangkan pula urutan event: memutar pesan lama setelah event yang lebih baru dapat menghasilkan keadaan yang tidak konsisten. Jika urutan penting, lakukan replay dalam kelompok yang terurut atau sediakan prosedur rekonsiliasi.

Praktik Aman dan Kesalahan Umum

• Jangan menghapus DLQ secara otomatis hanya karena usianya. Tetapkan retensi berdasarkan kebutuhan audit, privasi, dan kapasitas, lalu pastikan ada proses peninjauan.
• Batasi replay. Gunakan batch kecil, pantau metrik, dan hentikan proses bila tingkat kegagalan kembali naik.
• Uji jalur kegagalan. Simulasikan timeout, payload tidak valid, serta gangguan broker agar tim mengetahui perilaku sistem sebelum insiden nyata.
• Buat prosedur kepemilikan. Tentukan siapa yang menerima peringatan, menyelidiki pesan, menyetujui replay, dan mendokumentasikan penyelesaian.
• Jangan mengandalkan DLQ sebagai pengganti observabilitas. Metrik, log terstruktur, tracing, dan dashboard tetap diperlukan untuk memahami perjalanan pesan secara menyeluruh.

Kapan DLQ Diperlukan?

DLQ sangat berguna ketika pesan penting tidak boleh hilang begitu saja, pemrosesan dapat gagal karena data atau dependensi, dan tim membutuhkan cara aman untuk mengisolasi serta memperbaiki kegagalan. Untuk alur yang sangat sederhana, pencatatan kesalahan dan antrean retry mungkin cukup. Pilih mekanisme berdasarkan risiko bisnis, kebutuhan pemulihan, serta kemampuan tim mengoperasikannya.

Kesimpulan

Dead Letter Queue memberi sistem event-driven jalur terpisah untuk pesan yang tidak dapat diproses, tetapi manfaatnya bergantung pada desain operasional yang matang. Gabungkan DLQ dengan retry terbatas, jeda bertahap, metadata diagnostik, pemantauan, perlindungan data, dan replay yang aman. Dengan prosedur yang jelas, pesan gagal dapat menjadi sumber informasi untuk memperbaiki sistem, bukan penyebab antrean utama terus tersendat.