Consumer Acknowledgements #

Dalam arsitektur RabbitMQ, publish hanyalah setengah dari cerita.

Bagian lain yang sama pentingnya adalah:

Bagaimana broker mengetahui bahwa sebuah message telah berhasil diproses?

Jawabannya ada pada Consumer Acknowledgement (Ack/Nack).

Consumer acknowledgement adalah mekanisme yang menentukan:

• Apakah message dihapus dari queue
• Apakah message dikirim ulang
• Apakah message masuk DLQ

Artikel ini membahas bagaimana acknowledgement bekerja, mode yang tersedia, risiko kesalahan konfigurasi, dan bagaimana mendesain strategi ack yang sehat.

“Pesan yang diterima belum tentu selesai — sampai consumer sendiri menyatakan bahwa pekerjaan itu benar-benar tuntas.”

Apa Itu Consumer Acknowledgement? #

Consumer acknowledgement adalah sinyal dari consumer ke broker bahwa:

• Message telah diproses dengan sukses

Jika ack dikirim:

• Broker menghapus message dari queue

Jika ack tidak dikirim:

• Broker menganggap message belum selesai
• Message dapat dikirim ulang

Ack adalah bagian inti dari at-least-once delivery.

Mode Acknowledgement di RabbitMQ #

RabbitMQ memiliki dua mode utama:

1️⃣ Automatic Acknowledgement (Auto-Ack) #

Dalam mode ini:

• Broker menganggap message selesai segera setelah dikirim ke consumer
• Tidak ada konfirmasi eksplisit dari consumer

Keuntungan:

• Latency lebih rendah
• Implementasi sederhana

Risiko:

• Jika consumer crash sebelum proses selesai → message hilang

Auto-ack pada dasarnya menghasilkan at-most-once.

2️⃣ Manual Acknowledgement (Manual Ack) #

Dalam mode ini:

• Consumer harus memanggil basic.ack
• Message tetap dianggap in-flight sampai ack diterima

Keuntungan:

• Mendukung at-least-once
• Lebih aman untuk workload kritikal

Tradeoff:

• Perlu idempotency
• Perlu manajemen error

Manual ack adalah best practice untuk sistem production.

Jenis Acknowledgement #

RabbitMQ menyediakan beberapa operasi:

✅ basic.ack #

Menandakan message berhasil diproses.

❌ basic.nack #

Menandakan message gagal diproses.

Dapat disertai opsi:

• requeue = true → dikirim ulang
• requeue = false → masuk DLQ atau dihapus

🔁 basic.reject #

Mirip nack tetapi untuk satu message saja.

Apa yang Terjadi Jika Consumer Crash? #

Jika consumer:

• Menggunakan manual ack
• Crash sebelum mengirim ack

Maka:

• Message dikembalikan ke queue
• Akan dikirim ulang ke consumer lain atau yang sama

Ini adalah mekanisme inti at-least-once.

Ack dan Prefetch #

Prefetch menentukan:

• Berapa banyak unacked message yang boleh diterima consumer sekaligus

Jika prefetch = 10:

• Consumer bisa menerima 10 message
• Message ke-11 tidak dikirim sampai ada ack

Prefetch membantu mengontrol backpressure di sisi consumer.

Kesalahan Umum dalam Consumer Ack #

1️⃣ Lupa Mengirim Ack #

Message akan tetap unacked dan tidak pernah dihapus.

2️⃣ Ack Terlalu Cepat #

Mengirim ack sebelum proses benar-benar selesai.

Jika proses gagal setelah ack:

• Message sudah hilang

3️⃣ Selalu Requeue Tanpa Batas #

Jika selalu nack dengan requeue=true:

• Poison message akan loop tanpa akhir

4️⃣ Tidak Sinkron dengan Database Commit #

Urutan yang salah:

• Ack
• Lalu commit database

Jika crash di antara keduanya → data inconsistency.

Urutan yang benar:

1️⃣ Proses 2️⃣ Commit database 3️⃣ Kirim ack

Ack dan Delivery Guarantee #

Ack adalah pengendali utama delivery guarantee di sisi consumer.

Hubungan dengan DLQ #

Jika consumer memutuskan:

• basic.nack(requeue=false)

Dan queue memiliki DLX:

• Message akan masuk DLQ

Ack/Nack adalah titik keputusan apakah message selesai, dicoba ulang, atau diisolasi.

Best Practice Production #

• Gunakan manual acknowledgement
• Ack hanya setelah proses benar-benar sukses
• Gunakan retry limit + DLQ
• Gunakan prefetch sesuai kapasitas worker
• Pastikan consumer idempotent
• Monitor unacked message

Consumer acknowledgement adalah mekanisme kontrol kualitas pemrosesan.

Ringkasan #

Consumer acknowledgement menentukan:

• Kapan message dihapus
• Kapan message dikirim ulang
• Kapan message masuk DLQ

Manual ack adalah fondasi at-least-once.

Auto-ack hanya cocok untuk workload non-kritis.

Penutup #

Dalam sistem asynchronous, menerima pesan bukan berarti menyelesaikan pekerjaan.

Consumer acknowledgement adalah deklarasi resmi bahwa tugas telah selesai.

Menggunakannya dengan benar memberi sistem:

• Ketahanan
• Kontrol
• Kejelasan alur kegagalan

Menggunakannya dengan sembarangan dapat menyebabkan kehilangan data atau retry tanpa akhir.

Karena dalam arsitektur RabbitMQ, momen paling penting bukan saat pesan dikirim.

Tetapi saat pesan dinyatakan selesai.