DLQ #

Dead Letter Queue (DLQ): Konsep, Masalah Nyata, dan Implementasi di Amazon SQS

Dalam sistem terdistribusi modern, kegagalan bukanlah sesuatu yang bisa dihindari. Network glitch, bug logic, dependency eksternal yang lambat atau down, hingga data anomali adalah hal yang pasti terjadi. Yang membedakan sistem yang matang dan rapuh bukanlah apakah ia gagal, tetapi bagaimana ia gagal.

Salah satu mekanisme paling penting untuk menangani kegagalan dalam sistem berbasis message queue adalah Dead Letter Queue (DLQ).

Artikel ini akan membahas secara mendetail:

Apa itu DLQ dan masalah apa yang diselesaikannya
Kenapa retry saja tidak cukup
Konsep DLQ secara umum
Studi kasus nyata menggunakan Amazon SQS + DLQ
Alur pesan dari awal sampai masuk DLQ
Best practice desain DLQ di production

Artikel ini ditujukan untuk engineer backend, platform engineer, maupun architect yang membangun sistem event-driven atau async processing.

Apa Itu Dead Letter Queue (DLQ)? #

Dead Letter Queue (DLQ) adalah queue khusus yang digunakan untuk menyimpan pesan-pesan yang gagal diproses setelah melewati sejumlah percobaan (retry) yang telah ditentukan.

Alih-alih:

terus di-retry tanpa henti
dibuang tanpa jejak
atau membuat sistem macet

pesan tersebut dipindahkan ke DLQ untuk:

dianalisis
di-debug
diperbaiki
atau diproses ulang secara manual / otomatis

Secara sederhana:

DLQ adalah tempat karantina untuk pesan bermasalah.

Masalah Nyata Tanpa DLQ #

Mari kita lihat masalah klasik jika tidak menggunakan DLQ.

Contoh Kasus #

Sebuah sistem memiliki:

SQS Queue: order-created
Consumer: service order-processor

Tugas consumer:

Validasi order
Simpan ke database
Panggil payment service

Masalah Terjadi #

Tiba-tiba ada pesan dengan kondisi:

field amount = null
atau format JSON tidak sesuai
atau logic bug di consumer

Akibatnya:

Consumer selalu gagal memproses pesan ini
Message akan:
- muncul kembali setelah visibility timeout
- diproses ulang
- gagal lagi

Dampak #

Tanpa DLQ:

Pesan ini akan diproses berulang tanpa akhir
Menghabiskan resource
Mengganggu pesan lain (queue blocking)
Menyulitkan debugging

Inilah yang disebut poison message.

Kenapa Retry Saja Tidak Cukup? #

Retry memang penting, tapi tidak semua error bisa diselesaikan dengan retry.

Retry Cocok Untuk #

Network timeout
Dependency sementara down
Race condition

Retry Tidak Cocok Untuk #

Data invalid
Bug logic
Constraint database
Schema mismatch

Tanpa DLQ:

Retry → gagal → retry → gagal → loop selamanya

Dengan DLQ:

Retry dibatasi
Setelah limit tercapai → pesan dipindahkan ke DLQ

Konsep Dasar DLQ #

Secara umum, DLQ memiliki karakteristik:

Queue terpisah dari main queue
Tidak diproses oleh consumer utama
Menyimpan:
- payload pesan
- metadata kegagalan
Digunakan untuk:
- debugging
- reprocessing
- audit

Dead Letter Queue di Amazon SQS #

Amazon SQS memiliki dukungan native DLQ melalui fitur:

Redrive Policy #

Redrive policy memungkinkan:

Main queue mengirim pesan ke DLQ
Setelah pesan gagal diproses sebanyak maxReceiveCount

Komponen #

Main Queue: order-created
Dead Letter Queue: order-created-dlq

Studi Kasus: DLQ di SQS #

Arsitektur #

Producer
   |
   v
[SQS order-created]
   |
   v
Order Processor (Consumer)
   |
   |-- success --> done
   |
   |-- failure (retry)
   |
   |-- max retry reached
   v
[SQS order-created-dlq]

Alur Lengkap Pesan #

Pesan Dikirim #

Producer mengirim pesan:

{
  "order_id": "123",
  "amount": null
}

Consumer Gagal Memproses #

Consumer error saat validasi:

amount = null

Consumer tidak menghapus pesan dari queue.

Visibility Timeout #

Pesan menjadi invisible selama visibility timeout
Setelah timeout → pesan muncul kembali

Retry Berulang #

SQS menaikkan:

ApproximateReceiveCount

Contoh:

receive #1 → gagal
receive #2 → gagal
receive #3 → gagal

Masuk DLQ #

Jika maxReceiveCount = 3, maka:

Pada kegagalan ke-3
Pesan otomatis dipindahkan ke DLQ

Konfigurasi DLQ di SQS #

Buat DLQ #

Buat queue baru: order-created-dlq
Biasanya:
- Retention lebih lama (7–14 hari)
- Tidak ada consumer otomatis

Pasang Redrive Policy #

Di main queue order-created:

Dead-letter queue: order-created-dlq
maxReceiveCount: misal 3 atau 5

Artinya:

Jika satu pesan diterima lebih dari N kali tanpa berhasil dihapus, kirim ke DLQ.

Apa yang Ada di DLQ? #

Pesan di DLQ tetap berisi payload asli, plus metadata SQS:

Message Body
Message Attributes
ApproximateReceiveCount
Timestamp

Ini sangat penting untuk:

Root cause analysis
Replay pesan

Strategi Menangani Pesan di DLQ #

DLQ bukan akhir, tapi bagian dari workflow.

Manual Inspection #

Engineer membaca pesan
Cari root cause
Fix bug

Automated Reprocessing #

Setelah bug diperbaiki
Pesan dipindahkan kembali ke main queue

Filtering & Discard #

Jika data benar-benar invalid
Simpan sebagai audit
Tidak perlu diproses ulang

Best Practice DLQ di SQS #

Jangan Jadikan DLQ Sebagai Tempat Sampah #

DLQ harus:

Dimonitor
Dibersihkan
Ditindaklanjuti

Pasang Alarm #

Gunakan CloudWatch Alarm:

Jika DLQ memiliki pesan > 0
Itu sinyal ada masalah serius

Tentukan maxReceiveCount dengan Bijak #

Umumnya:

3–5 untuk error non-transient
Lebih besar jika dependency sering fluktuatif

Pisahkan Error Transient vs Permanent #

Di consumer:

Error transient → retry
Error permanent → log dan fail cepat

Simpan Context Error #

Tambahkan:

correlation id
request id
version

Agar debugging DLQ lebih mudah.

Kesalahan Umum dalam Implementasi DLQ #

Tidak pernah melihat DLQ
maxReceiveCount terlalu besar
DLQ diproses otomatis tanpa filtering
Menghapus pesan DLQ tanpa analisa

Kapan DLQ Wajib Digunakan? #

DLQ wajib jika:

Sistem async / event-driven
Tidak boleh kehilangan data
Processing kompleks
Dependency banyak

Jika Anda memakai:

SQS
Pub/Sub
Kafka

Maka konsep DLQ (atau ekuivalennya) bukan opsional.

Penutup #

Dead Letter Queue adalah salah satu fondasi penting dalam membangun sistem yang resilient, observable, dan maintainable.

DLQ bukan sekadar fitur teknis, tapi alat desain sistem untuk mengakui bahwa kegagalan itu normal — dan harus ditangani dengan elegan.

Jika sistem Anda sudah async tapi belum punya DLQ:

Itu bukan soal jika akan bermasalah, tapi kapan.