Digital Transformation

Dead Letter Queue (DLQ)

Vito Atmo
Vito Atmo·1 Mei 2026·2 kali dibaca·2 min baca

TL;DR: Dead letter queue (DLQ) menampung pesan atau job yang gagal diproses berkali-kali oleh sistem antrian. DLQ mencegah retry tak berujung yang menghabiskan resource, dan memberi tim engineering jejak audit untuk debug. Setiap sistem produksi yang pakai message queue wajib punya DLQ.

Apa itu Dead Letter Queue?

Dead letter queue adalah antrian sekunder yang menerima pesan saat antrian utama gagal memprosesnya melebihi batas retry. Misal pesan checkout gagal diproses karena format JSON rusak, setelah 5 percobaan gagal, pesan dipindahkan ke DLQ supaya antrian utama tetap lancar untuk pesan lain. Konsep ini mirip circuit breaker tapi pada level pesan, bukan service.

Tanpa DLQ, pesan rusak akan dicoba ulang terus menerus, memakan resource dan memblokir antrian. Dengan DLQ, sistem isolasi masalah supaya bisa diinvestigasi tanpa mengganggu trafik produksi.

Skenario Pemicu DLQ

PenyebabContoh
Format pesan rusakJSON malformed, schema mismatch
Dependency matiDatabase down saat retry habis
Bug di consumerException tidak ter-handle
Idempotency conflictDuplikasi yang gagal dideteksi

DLQ biasa dipakai bersama idempotency key supaya retry aman dan deduplikasi rapi.

Kenapa Penting?

Untuk tim produk Indonesia yang menjalankan webhook payment gateway, marketing automation, atau pipeline data, DLQ adalah safety net wajib. Dalam beberapa proyek client yang saya tangani, penambahan DLQ + monitoring memangkas waktu deteksi insiden dari rata rata 2 sampai 4 jam menjadi di bawah 30 menit, karena tim langsung tahu pesan apa yang stuck dan kenapa.

DLQ juga komponen penting di praktik SRE modern. Selalu pasang alarm pada DLQ supaya pesan tidak menumpuk diam diam.

Pertanyaan Umum

Berapa kali retry sebelum pesan masuk DLQ?

Standar industri 3 sampai 5 retry dengan exponential backoff. Lebih dari itu biasanya membuang biaya tanpa hasil.

Apakah pesan di DLQ harus diproses ulang?

Tidak otomatis. Tim engineering harus investigasi root cause dulu, perbaiki bug atau data, baru replay pesan. Replay tanpa fix sering memperburuk situasi.

Bagikan