Dead Letter Queue (DLQ): Ke Mana Perginya Tugas yang Gagal Diproses?

Bayangin Kurir Paket Nyari Alamat Palsu...

Di artikel Message Broker (RabbitMQ), kita tahu Budi menggunakan "Antrean Surat" agar API-nya cepat. Ada Worker (Pekerja) yang tugasnya membaca antrean dan mengirimkan Email Struk ke pembeli.

Bayangin pembelinya salah ngetik email menjadi budi@gmailll.con. Pekerja mencoba mengirim email, dan GAGAL. Karena Pekerja ini sangat gigih, ia mengembalikan tugas itu ke atas antrean untuk dicoba lagi nanti.
5 Menit kemudian dicoba lagi, GAGAL.
Pekerja terus mencoba 1000 kali tanpa henti, sampai antrean di belakangnya (surat milik pelanggan lain yang email-nya benar) MACET TOTAL karena terhalang oleh satu surat cacat ini!

Masalahnya: Infinite Retry Loop (Perulangan Gagal Tanpa Henti)

Kita tidak bisa membiarkan Pekerja terus-terusan mengurus pesan (Message) yang *error*. Tapi kita juga TIDAK BOLEH membuang/menghapus pesan itu secara diam-diam, karena mungkin saja *error*-nya terjadi karena salah koding (Bug) dan perusahaan butuh buktinya.

Nah, Di Sinilah 'Dead Letter Queue (DLQ)' Masuk!

Arsitek Backend membuat satu ruangan khusus yang disebut Dead Letter Queue (Antrean Surat Mati / DLQ).

• Saat Pekerja gagal mengirim surat, ia akan menambahkan tanda (Cap): "Gagal 1x".
• Pekerja terus mencoba. Setelah surat itu dicap "Gagal 5x" (batas maksimal retri), sistem RabbitMQ akan berkata: "Cukup! Surat ini sudah jadi mayat."
• Alih-alih dibuang, surat cacat itu DILEMPAR PINDAH ke ruangan DLQ (Sebuah antrean sunyi yang tidak dieksekusi oleh siapa-siapa).
• Antrean utama kini kembali lancar dan bisa melayani pembeli lain.

Lalu buat apa ditaruh di DLQ?
Keesokan paginya, Budi si *Programmer* akan membuka ruangan DLQ. Budi membaca pesan-pesan cacat tersebut, menyadari ada Bug di *script* email-nya, memperbaiki kodenya, dan MEMUTAR ULANG (Re-queue) isi DLQ tersebut kembali ke antrean utama agar diproses dengan kode yang baru. Tidak ada data pelanggan yang terbuang sia-sia!