Delivery #

Dalam lifecycle RabbitMQ, setelah message:

• Dipublish
• Dirutekan
• Disimpan (jika persistent)

Tahap berikutnya adalah delivery ke consumer.

Di sinilah sistem mulai berinteraksi dengan logic bisnis.

Namun delivery bukan sekadar mengirim data dari queue ke aplikasi.

Ia melibatkan:

• Flow control
• Prefetch
• Ack/Nack
• Redelivery
• Duplicate handling

Artikel ini membahas tahap delivery sebagai fase kritikal dalam message lifecycle RabbitMQ.

“Sebuah pesan belum selesai perjalanannya ketika ia masuk ke queue — ia baru benar-benar berarti ketika berhasil diproses.”

Apa Itu Delivery? #

Delivery adalah proses ketika broker:

• Mengambil message dari queue
• Mengirimkannya ke consumer melalui channel
• Menunggu acknowledgement

RabbitMQ menggunakan model push-based delivery.

Artinya broker secara aktif mendorong message ke consumer.

Consumer tidak melakukan polling manual.

Posisi Delivery dalam Lifecycle #

1. Diagram Lifecycle hingga Delivery #

Producer
   |
   v
Exchange
   |
   v
Queue
   |
   | push
   v
Consumer
   |
   v
Ack / Nack

Delivery terjadi setelah message berada di queue dan siap dikonsumsi.

Ready vs Unacknowledged Message #

Dalam queue terdapat dua status penting:

• Ready message → belum dikirim ke consumer
• Unacked message → sudah dikirim tetapi belum di-ack

Message berpindah dari ready ke unacked saat delivery.

Jika consumer mengirim ack:

• Message dihapus permanen

Jika connection terputus sebelum ack:

• Message kembali ke ready state (requeue)

Prefetch: Mengontrol Aliran Delivery #

Prefetch menentukan berapa banyak unacked message yang boleh diterima consumer sekaligus.

Contoh:

prefetch = 5

Artinya:

• Consumer hanya menerima maksimal 5 message yang belum di-ack
• Broker tidak akan mengirim message ke-6 sebelum salah satu di-ack

Prefetch adalah mekanisme backpressure dari sisi consumer.

Tanpa prefetch yang tepat, satu consumer bisa dibanjiri message.

Manual Ack vs Auto Ack #

Auto Ack #

• Message dianggap selesai saat dikirim
• Jika consumer crash → message hilang

Manual Ack (Direkomendasikan) #

• Consumer mengirim ack setelah sukses memproses
• Jika crash sebelum ack → message di-redeliver

Dalam production system, manual ack hampir selalu digunakan.

Redelivery dan Duplicate #

Karena RabbitMQ bersifat at-least-once delivery, maka:

• Message bisa dikirim ulang
• Duplicate processing mungkin terjadi

Redelivery bisa terjadi jika:

• Consumer crash
• Connection drop
• Nack dengan requeue=true

Consumer harus dirancang idempotent.

Delivery dalam Quorum Queue #

Pada quorum queue:

• Message dikirim oleh leader
• State unacked tetap tercatat dalam log
• Jika leader mati, leader baru melanjutkan delivery

Ordering tetap dijaga oleh Raft log.

Namun ada tambahan latency jika terjadi leader election.

Flow Control dan Delivery #

Jika:

• Consumer lambat
• Prefetch besar
• Banyak unacked message

Queue bisa membengkak.

Jika memory watermark tercapai:

• Broker bisa mengaktifkan flow control
• Producer diblokir

Delivery dan publishing saling memengaruhi melalui tekanan sistem.

Delivery Failure Scenario #

Consumer Crash #

• Message unacked dikembalikan ke ready
• Dikirim ke consumer lain

Nack tanpa Requeue #

• Message bisa masuk DLQ

Poison Message #

Message gagal terus-menerus dan selalu di-requeue.

Solusi:

• Gunakan dead-letter exchange
• Batasi retry

Delivery Guarantee #

RabbitMQ default memberikan:

At-least-once delivery

Artinya:

• Message akan dikirim minimal satu kali
• Bisa lebih dari satu kali

RabbitMQ tidak menjamin exactly-once.

Exactly-once harus ditangani di level aplikasi.

Best Practice Production #

• Gunakan manual ack
• Atur prefetch sesuai kapasitas consumer
• Buat consumer idempotent
• Gunakan DLQ untuk error handling
• Monitor unacked message count

Delivery yang stabil bergantung pada desain consumer, bukan hanya broker.

Ringkasan #

Penutup #

Delivery adalah fase di mana RabbitMQ berinteraksi langsung dengan logic bisnis.

Di sinilah:

• Duplicate bisa terjadi
• Data bisa hilang jika salah konfigurasi
• Sistem bisa overload jika salah desain

Message lifecycle tidak berhenti di queue.

Ia benar-benar selesai ketika consumer memproses dan mengakui pesan dengan benar.

Dalam arsitektur messaging yang matang, delivery bukan sekadar pengiriman — ia adalah fase di mana keandalan sistem benar-benar diuji.