Requeue vs Drop #

Dalam RabbitMQ, kegagalan pemrosesan adalah hal yang normal.

Consumer bisa gagal karena:

• Error logika bisnis
• Timeout ke database
• Service dependency down
• Data tidak valid

Pada titik ini, consumer harus membuat keputusan penting:

• Requeue → kirim ulang pesan ke queue
• Drop → buang pesan (atau kirim ke DLQ)

Keputusan ini sangat menentukan stabilitas, konsistensi, dan ketahanan sistem.

Artikel ini membahas requeue vs drop sebagai bagian dari error handling strategy dalam RabbitMQ.

“Ketika sebuah pesan gagal diproses, sistem harus memilih: mencobanya lagi — atau melepaskannya.”

Apa Itu Requeue? #

Requeue terjadi ketika consumer mengirim:

• basic.nack dengan requeue = true
• basic.reject dengan requeue = true

Artinya:

“Pesan ini gagal sekarang, coba lagi nanti.”

Broker akan:

• Mengembalikan message ke queue
• Biasanya ditempatkan kembali di posisi terdepan atau sesuai implementasi internal
• Mengirim ulang ke consumer (yang sama atau berbeda)

Requeue mempertahankan pesan dalam sistem.

Apa Itu Drop? #

Drop terjadi ketika consumer mengirim:

• basic.nack dengan requeue = false
• basic.reject dengan requeue = false

Artinya:

“Pesan ini tidak boleh diproses lagi di queue ini.”

Jika queue memiliki Dead Letter Exchange (DLX):

• Message akan dikirim ke DLQ

Jika tidak ada DLX:

• Message dihapus permanen

Drop adalah keputusan final terhadap pesan.

Perbandingan Requeue vs Drop #

Requeue cocok untuk error transient. Drop cocok untuk error permanen.

Error Transient vs Error Permanen #

Keputusan requeue atau drop harus berdasarkan tipe error.

Error Transient #

Contoh:

• Database timeout
• Network glitch
• Service dependency down

Strategi:

Requeue dengan retry terbatas.

Error Permanen #

Contoh:

• Format data salah
• Validation gagal
• Business rule tidak terpenuhi

Strategi:

Drop dan kirim ke DLQ.

Risiko Requeue Tanpa Batas #

Jika selalu requeue tanpa kontrol:

• Message akan terus gagal
• Queue tidak pernah bersih
• Consumer sibuk memproses pesan yang sama
• Throughput menurun drastis

Ini disebut poison message problem.

Tanpa mekanisme pembatasan retry, sistem bisa macet.

Strategi Aman: Retry dengan Batasan #

Pendekatan umum:

• Gunakan DLX sebagai retry queue
• Tambahkan TTL untuk delay
• Batasi jumlah retry dengan header counter

Alur umum:

1. Message gagal
2. Nack dengan requeue=false
3. Masuk ke retry queue (DLX)
4. Setelah TTL, kembali ke queue utama
5. Hitung retry count
6. Jika melebihi batas → drop permanen ke DLQ final

Requeue langsung jarang digunakan untuk retry kompleks.

Requeue dan Ordering #

Requeue bisa memengaruhi ordering.

Karena message yang gagal bisa kembali dan diproses setelah message lain.

FIFO tidak selalu terjaga dalam skenario requeue berulang.

Jika ordering penting, desain retry harus lebih hati-hati.

Requeue dalam Quorum Queue #

Pada quorum queue:

• Redelivery tetap tercatat dalam Raft log
• Konsistensi tetap dijaga
• Duplicate tetap mungkin terjadi

Quorum queue tidak menghilangkan risiko infinite retry.

Strategi aplikasi tetap diperlukan.

Drop dan Observability #

Jika memilih drop:

• Pastikan ada DLQ
• Pantau DLQ depth
• Logging harus jelas

Drop tanpa observability sama berbahayanya dengan silent drop saat routing.

Best Practice Production #

• Jangan requeue tanpa batas
• Pisahkan retry sementara dan DLQ permanen
• Bedakan error transient dan permanen
• Gunakan header retry-count
• Monitor DLQ dan requeue rate
• Hindari retry langsung tanpa delay

Requeue adalah alat, bukan solusi.

Ringkasan #

Penutup #

Requeue vs drop bukan sekadar konfigurasi teknis.

Ia adalah keputusan arsitektural tentang bagaimana sistem menghadapi kegagalan.

Sistem yang selalu requeue tanpa kontrol akan runtuh oleh pesan yang tidak pernah selesai.

Sistem yang selalu drop tanpa observability akan kehilangan data tanpa jejak.

Dalam arsitektur RabbitMQ yang matang, setiap kegagalan harus dipetakan dengan jelas:

• Apakah ini layak dicoba lagi?
• Atau memang harus dihentikan di sini?

Karena dalam sistem asynchronous, cara kita menangani kegagalan sering kali lebih penting daripada cara kita menangani keberhasilan.