Acknowledgement #

Dalam lifecycle RabbitMQ, tahap terakhir yang menentukan nasib sebuah message adalah acknowledgement (ack).

Tanpa ack:

• Message tetap dianggap belum selesai
• Bisa dikirim ulang
• Bisa menyebabkan duplicate processing

Dengan ack yang salah:

• Message bisa hilang
• Data bisa inkonsisten
• Retry bisa tak terkendali

Artikel ini membahas acknowledgement secara mendalam sebagai fase akhir dalam message lifecycle RabbitMQ.

“Dalam sistem asynchronous, pesan tidak dianggap selesai saat dikirim — ia selesai saat diakui.”

Apa Itu Acknowledgement? #

Acknowledgement (ack) adalah sinyal dari consumer ke broker bahwa:

“Message ini sudah berhasil saya proses.”

Setelah broker menerima ack:

• Message dihapus permanen dari queue
• Tidak akan dikirim ulang

Jika ack tidak pernah dikirim:

• Message tetap dalam status unacked
• Akan di-redeliver jika connection terputus

Posisi Ack dalam Lifecycle #

1. Diagram Tahap Akhir Lifecycle #

Queue
   |
   | push
   v
Consumer
   |
   | process business logic
   v
Ack / Nack
   |
   v
Message dihapus / direqueue / masuk DLQ

Ack adalah keputusan final terhadap message.

Manual Ack vs Auto Ack #

Auto Ack #

• Message dianggap selesai saat dikirim
• Broker langsung menghapus message

Risiko:

• Jika consumer crash sebelum memproses → message hilang

Auto ack jarang digunakan di production.

Manual Ack (Direkomendasikan) #

• Consumer memanggil basic.ack setelah sukses
• Broker menghapus message hanya setelah ack diterima

Ini memungkinkan recovery jika terjadi crash.

Negative Acknowledgement (Nack) #

Consumer dapat mengirim:

• basic.nack
• basic.reject

Dengan opsi:

• requeue = true
• requeue = false

Jika requeue=true:

• Message dikembalikan ke queue

Jika requeue=false:

• Message dibuang atau masuk Dead Letter Exchange

Nack memberi kontrol terhadap error handling.

Multiple Ack #

RabbitMQ mendukung multiple acknowledgement:

• Ack beberapa message sekaligus
• Mengurangi overhead network

Namun harus digunakan hati-hati.

Jika salah, bisa menghapus message yang belum selesai diproses.

Redelivery dan Duplicate #

Karena RabbitMQ default-nya at-least-once:

• Message bisa dikirim ulang jika tidak di-ack
• Duplicate bisa terjadi

Consumer harus:

• Idempotent
• Atau memiliki mekanisme deduplikasi

Ack tidak mencegah duplicate jika crash terjadi sebelum ack terkirim.

Ack dalam Quorum Queue #

Pada quorum queue:

• Status unacked tetap tercatat dalam log Raft
• Jika leader mati sebelum ack diproses, message bisa di-redeliver

Ordering tetap dijaga.

Namun duplicate tetap mungkin terjadi.

Poison Message dan Retry Loop #

Jika message selalu gagal dan selalu di-nack dengan requeue=true:

• Bisa terjadi infinite retry
• Queue tidak pernah bersih

Solusi umum:

• Gunakan Dead Letter Exchange
• Batasi jumlah retry
• Gunakan retry queue dengan delay

Ack dan nack harus dirancang bersama strategi retry.

Delivery Tag dan Channel Scope #

Setiap message memiliki delivery tag unik dalam satu channel.

Ack harus dikirim menggunakan:

• Channel yang sama
• Delivery tag yang benar

Ack dari channel berbeda tidak valid.

Kesalahan ini sering terjadi dalam implementasi multithreaded.

Crash Scenario #

Consumer Crash Sebelum Ack #

• Broker mendeteksi connection closed
• Message unacked di-requeue
• Dikirim ulang ke consumer lain

Consumer Crash Setelah Proses, Sebelum Ack #

• Message diproses
• Ack belum terkirim
• Message dikirim ulang

Inilah alasan idempotency sangat penting.

Best Practice Production #

• Gunakan manual ack
• Kirim ack hanya setelah transaksi selesai
• Gunakan DLQ untuk error permanen
• Hindari requeue tanpa batas
• Pastikan consumer idempotent
• Monitor unacked message count

Ack adalah bagian dari reliability contract.

Ringkasan #

Penutup #

Acknowledgement adalah titik akhir dari perjalanan sebuah message.

Di sinilah ditentukan apakah message:

• Selesai diproses
• Dicoba lagi
• Atau diisolasi karena gagal

Tanpa pemahaman yang benar tentang ack dan nack, sistem RabbitMQ akan tampak bekerja — tetapi diam-diam menyimpan potensi duplicate, retry tak terkendali, atau bahkan kehilangan data.

Dalam arsitektur messaging yang matang, ack bukan sekadar sinyal teknis.

Ia adalah komitmen bahwa pekerjaan telah benar-benar selesai.