Dead Letter Queue (DLQ) & Retry Policy: Menyelamatkan Pesan Nyasar di RabbitMQ Tanpa Bikin Worker Macet

Kalian sedang ngejalanin sistem e-commerce yang lumayan sibuk. Begitu pelanggan berhasil bayar, sistem nerbitin (publish) event order.paid ke antrean RabbitMQ. Dari situ, worker bakal nyetak resi pengiriman, motong stok gudang, dan ngirim invoice lewat email.

Tiba-tiba, API penyedia logistik pihak ketiga mengalami gangguan (down). Worker pengiriman pun gagal memproses pesan itu. Nah, dari titik ini kita bakal lihat gimana jebakannya muncul.

Apa yang biasanya dilakukan developer pemula? Mereka nangkep exception (try...except), lalu manggil baris sakti ini:

# ANTI-PATTERN: Menolak pesan dan menyuruh RabbitMQ memasukkannya kembali ke antrean
channel.basic_nack(delivery_tag=method.delivery_tag, requeue=True)

Hasilnya? Pesan langsung dibalikin ke depan antrean, diambil lagi oleh worker dalam hitungan mikrodetik, gagal lagi, dikembalikan lagi, dan begitu terus jutaan kali per menit. 😅

Fenomena ini disebut poison message loop. Bukan cuma bikin antrean macet total (head-of-line blocking), CPU server worker kalian bakal langsung melonjak ke 100%!

Terus, gimana cara nangani pesan gagal secara elegan tanpa ngeblokir antrean lain? Jawabannya ada dua senjata: retry policy dan dead letter queue (DLQ).

Apa Sih Sebenarnya Dead Letter Exchange Itu?

Di RabbitMQ, dead lettering bukanlah fitur magis yang rumit. Dead Letter Exchange (DLX) sebenarnya cuma exchange AMQP biasa yang kita daftarkan ke sebuah antrean lewat argumen konfigurasi x-dead-letter-exchange.

Sebuah pesan dianggap "mati" (dead-lettered) dan diteruskan otomatis oleh broker RabbitMQ ke DLX hanya kalau terjadi salah satu dari tiga kondisi ini.

Pertama, pesan ditolak eksplisit oleh worker pakai basic.reject atau basic.nack dengan parameter requeue=False.

Kedua, masa berlaku pesan habis (TTL expired). Pesan punya batas waktu hidup (Time-To-Live), baik di level antrean (x-message-ttl) atau per pesan individual, dan waktunya kedaluwarsa sebelum sempat diproses.

Ketiga, antrean melebihi batas (max length reached). Antrean utama udah nyampe batas maksimum pesan (x-max-length), jadi pesan paling awal dibuang ke DLX.

Kenapa Butuh Retry Bertingkat Sih?

Ketika sebuah pesan gagal diproses, penyebabnya biasanya terbagi dua kategori.

Ada transient failure, alias kesalahan sementara: jaringan glitch sesaat, database lagi lock contention, atau API pihak ketiga lambat merespons. Solusinya, coba lagi beberapa detik kemudian (retry with backoff).

Ada juga permanent failure, alias kesalahan permanen: payload JSON rusak, ID pengguna nggak valid, atau bug logika di kode. Berapa kali pun dicoba ulang, pesan ini nggak akan pernah berhasil!

Strategi idealnya, kasih kesempatan retry otomatis beberapa kali dengan jeda yang makin lama (misal 5 detik, 15 detik, 60 detik). Kalau setelah 3 atau 5 percobaan masih tetap gagal, barulah pesannya dilempar ke Dead Letter Queue (DLQ) akhir buat dianalisis developer.

Pola Andalan: Delayed Retry via TTL dan DLX

Salah satu pola paling andal di RabbitMQ tanpa plugin eksternal adalah memanfaatkan antrean perantara (retry queue) yang dipasangi TTL.

Pertama, worker mengonsumsi pesan dari main queue (orders.process). Kalau gagal sementara, worker mem-publish pesan ke retry.exchange sambil nyatet counter percobaan di header x-retries: 1.

Kedua, pesan mendarat di retry queue (orders.retry.30s). Antrean ini nggak punya worker sama sekali! Dia cuma dipasangi x-message-ttl: 30000 (30 detik) dan x-dead-letter-exchange: orders.exchange.

Ketiga, setelah 30 detik tidur di retry queue, RabbitMQ otomatis menganggap pesan itu "expired" dan meneruskannya kembali ke orders.process buat dicoba ulang oleh worker.

Keempat, kalau header x-retries udah nyampe batas maksimum (misal 3), worker langsung ngirim pesan ke orders.dlq (terminal queue). Selesai, nggak ada drama berulang. 😎

Contoh Implementasi di Python (Pika / Aio-Pika)

Berikut contoh deklarasi antrean tangguh pakai Python dan pustaka pika:

import json
import pika

connection = pika.BlockingConnection(pika.ConnectionParameters(host="localhost"))
channel = connection.channel()

# 1. Buat Dead Letter Exchange (DLX) dan Antrean DLQ
channel.exchange_declare(exchange="dlx.orders", exchange_type="direct")
channel.queue_declare(queue="orders.dlq", durable=True)
channel.queue_bind(exchange="dlx.orders", queue="orders.dlq", routing_key="order.failed")

# 2. Buat Main Exchange & Queue dengan konfigurasi DLX bawaan
channel.exchange_declare(exchange="orders.exchange", exchange_type="direct")

queue_args = {
    "x-dead-letter-exchange": "dlx.orders",
    "x-dead-letter-routing-key": "order.failed",
}

channel.queue_declare(queue="orders.main", durable=True, arguments=queue_args)
channel.queue_bind(exchange="orders.exchange", queue="orders.main", routing_key="order.process")

# 3. Callback Worker yang Aman
def on_message(ch, method, properties, body):
    try:
        data = json.loads(body)
        # Eksekusi logika bisnis (misal call API logistik)...
        process_shipment(data)
        ch.basic_ack(delivery_tag=method.delivery_tag)
    except TransientNetworkError:
        # Kesalahan sementara: bisa dipublish ke retry queue
        print("Network timeout, routing to retry...")
        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)  # Masuk ke DLQ jika batas habis
    except Exception as e:
        # Kesalahan permanen: buang langsung ke DLQ, JANGAN REQUEUE!
        print(f"Permanent error: {e}. Moving to DLQ.")
        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)

channel.basic_consume(queue="orders.main", on_message_callback=on_message)
print("Worker siap melayani pesanan...")
channel.start_consuming()

Terus, Pesan yang Nyangkut di DLQ Diapain?

Antrean DLQ bukan tempat sampah tempat data dilupakan gitu aja. DLQ itu brankas penyelamat, dan ada tiga hal yang wajib kalian lakukan.

Pasang alerting terintegrasi. Setel metrik monitoring (misal via Prometheus RabbitMQ Exporter) buat bunyiin alarm begitu jumlah pesan di orders.dlq lebih besar dari 0.

Lakukan inspeksi dan root cause analysis. Developer bisa lihat payload asli dan header error di RabbitMQ Management UI buat mendiagnosis apakah ada payload aneh atau bug baru.

Terakhir, jalankan replay message. Setelah bug di kode diperbaiki atau layanan pihak ketiga kembali online, kalian bisa pakai CLI rabbitmqadmin atau script sederhana buat mindahin (shovel) pesan dari DLQ balik ke antrean utama. Nggak ada transaksi pelanggan yang hilang!

Jangan Biarkan Satu Pesan Gagal Nurunin Sistemmu

Sistem terdistribusi yang tangguh (resilient) bukan sistem yang nggak pernah gagal, melainkan sistem yang tahu cara memperlakukan kegagalan dengan anggun.

Dengan mengganti requeue=True yang ceroboh jadi kombinasi retry backoff dan dead letter queue, kalian melindungi worker backend dari kelumpuhan. Setiap pesan penting tetap tersimpan dengan selamat, siap diproses ulang kapan pun bug-nya kelar dibetulin.

Selamat ber-messaging ria, dan semoga nggak ada lagi pesanan pelanggan yang nyasar ke void! 👋