Not Using DLQ #

Dalam sistem berbasis RabbitMQ, kegagalan adalah sesuatu yang pasti terjadi.

Message bisa gagal karena:

• Bug pada consumer
• Data tidak valid
• Dependency down
• Timeout
• Perubahan schema

Namun salah satu anti-pattern paling berbahaya adalah:

Tidak menggunakan Dead Letter Queue (DLQ) sama sekali.

Sistem tetap berjalan. Message tetap dipublish. Consumer tetap aktif.

Tetapi kegagalan tidak pernah diisolasi.

Artikel ini membahas mengapa tidak menggunakan DLQ adalah kesalahan arsitektural serius.

“Kegagalan yang tidak terlihat bukan berarti tidak terjadi — ia hanya menunggu menjadi masalah yang lebih besar.”

Apa yang Terjadi Jika Tidak Ada DLQ? #

Jika queue tidak memiliki konfigurasi DLX/DLQ, maka saat terjadi:

• nack(requeue=false)
• TTL expired
• Max-length overflow

Message akan:

• Dihapus permanen

Tanpa jejak.

Atau jika consumer selalu requeue=true, maka:

• Message akan terus diproses ulang tanpa batas

Kedua kondisi ini sama-sama berbahaya.

Dampak 1️⃣: Silent Data Loss #

Tanpa DLQ, ketika consumer memutuskan requeue=false:

• Message langsung hilang
• Tidak ada audit
• Tidak ada investigasi

Dalam sistem bisnis:

• Order bisa hilang
• Payment event bisa hilang
• Notifikasi bisa tidak terkirim

Dan tidak ada cara untuk mengetahuinya.

Dampak 2️⃣: Infinite Retry Loop #

Jika untuk menghindari kehilangan data kita selalu requeue=true:

• Poison message akan terus diproses
• Queue starvation terjadi
• Throughput turun drastis

Tanpa DLQ, sistem hanya punya dua pilihan ekstrem:

• Hilang
• Atau retry tanpa batas

Tidak ada mekanisme isolasi.

Dampak 3️⃣: Tidak Ada Observability #

DLQ adalah indikator kesehatan sistem.

Jika DLQ depth meningkat:

• Ada bug
• Ada mismatch schema
• Ada dependency yang bermasalah

Tanpa DLQ:

• Kegagalan tidak terukur
• Error hanya terlihat di log (jika ada)
• Monitoring menjadi tidak lengkap

Sistem terlihat sehat — padahal tidak.

Mengapa Orang Tidak Menggunakan DLQ? #

Beberapa alasan umum:

• “Belum butuh”
• “Sistem masih kecil”
• “Nanti saja kalau sudah production”
• “Takut terlalu kompleks”

Padahal menambahkan DLQ sejak awal jauh lebih murah daripada memperbaiki sistem setelah kehilangan data.

DLQ Bukan Tempat Sampah #

Perlu dipahami:

DLQ bukan tempat membuang masalah.

Ia adalah:

• Mekanisme isolasi
• Alat observability
• Jalur investigasi

DLQ harus:

• Dimonitor
• Diberi alert
• Dikelola secara sadar

Arsitektur yang Sehat #

Pendekatan yang disarankan:

1️⃣ Setiap queue bisnis penting memiliki DLX 2️⃣ Retry dibatasi dengan retry-count 3️⃣ Jika melebihi batas → kirim ke DLQ final 4️⃣ DLQ dipantau dan dianalisis

Contoh alur:

Main Queue
   |
   | error
   v
Retry Queue (TTL + backoff)
   |
   | melebihi batas
   v
Final DLQ

Ini memberi tiga lapisan perlindungan:

• Retry terkontrol
• Isolasi poison message
• Observability

Perbandingan Singkat #

DLQ bukan fitur opsional dalam sistem produksi.

Ia adalah safety net.

Kapan Boleh Tidak Menggunakan DLQ? #

Secara realistis:

• Prototipe sangat kecil
• Sistem non-critical
• Eksperimen sementara

Namun begitu sistem menyentuh:

• Data bisnis
• Transaksi finansial
• User-facing workflow

DLQ harus menjadi bagian dari desain.

Ringkasan #

Tidak menggunakan DLQ adalah anti-pattern karena:

• Menghilangkan mekanisme isolasi kegagalan
• Menyebabkan data loss atau retry loop
• Mengurangi observability

DLQ adalah:

• Jaring pengaman
• Indikator kesehatan sistem
• Fondasi reliability

Penutup #

Dalam sistem asynchronous, kegagalan bukan pertanyaan “apakah akan terjadi” — tetapi “kapan akan terjadi”.

Tanpa DLQ, sistem tidak memiliki cara yang elegan untuk menangani kegagalan tersebut.

Ia hanya bisa memilih antara kehilangan data atau mencoba tanpa henti.

Arsitektur yang matang selalu memiliki jalur isolasi untuk pesan yang gagal.

Karena dalam sistem produksi, bukan hanya keberhasilan yang harus dirancang.

Kegagalan juga harus memiliki tempatnya sendiri.