Publisher Confirms #

Dalam arsitektur messaging, banyak orang fokus pada sisi consumer:

• Ack
• Retry
• DLQ
• Idempotency

Namun ada sisi lain yang tidak kalah penting:

Bagaimana producer tahu bahwa pesan benar-benar diterima dan disimpan oleh broker?

Di sinilah Publisher Confirms berperan.

Artikel ini membahas secara mendalam apa itu publisher confirms, bagaimana ia bekerja, kapan harus digunakan, dan bagaimana ia berinteraksi dengan delivery guarantee.

“Mengirim pesan bukan berarti pesan sudah aman — sampai broker sendiri mengakuinya.”

Mengapa Publisher Confirms Diperlukan? #

Tanpa publisher confirms, alur publish biasanya seperti ini:

1️⃣ Producer mengirim message 2️⃣ TCP write berhasil 3️⃣ Producer menganggap publish sukses

Namun kenyataannya:

• Broker bisa crash sebelum menyimpan ke disk
• Network bisa terputus
• Message bisa belum direplikasi (quorum)

Producer tidak tahu apakah message benar-benar aman.

Ini berisiko menyebabkan silent data loss di sisi producer.

Apa Itu Publisher Confirms? #

Publisher confirms adalah mekanisme di mana:

• Broker mengirim acknowledgment kembali ke producer
• Setelah message diterima dan (jika perlu) disimpan dengan aman

Alurnya:

1️⃣ Producer publish message 2️⃣ Broker menerima 3️⃣ Broker menyimpan (memory/disk/replication) 4️⃣ Broker mengirim confirm (ack) ke producer 5️⃣ Producer tahu message aman

Publisher confirm adalah jaminan dari broker.

Bagaimana Cara Kerjanya? #

Producer mengaktifkan confirm mode pada channel.

Setiap message memiliki sequence number.

Broker akan mengirim:

• basic.ack → publish sukses
• basic.nack → publish gagal

Producer dapat:

• Retry
• Log error
• Fail request upstream

Confirm dan Durability #

Perilaku confirm bergantung pada konfigurasi queue.

1️⃣ Non-Persistent + Classic Queue #

Confirm bisa terjadi setelah broker menerima di memory.

Jika broker crash setelah confirm tetapi sebelum disk flush:

• Message bisa hilang.

2️⃣ Persistent + Durable Queue #

Confirm terjadi setelah message ditulis ke disk.

Lebih aman.

3️⃣ Quorum Queue #

Confirm terjadi setelah message direplikasi ke mayoritas node (Raft commit).

Ini memberikan durability paling kuat.

Publisher confirm + quorum = jaminan producer paling tinggi.

Publisher Confirms vs Transactions #

RabbitMQ juga memiliki mode transaksi (tx.select).

Namun transaksi:

• Lebih lambat
• Berat
• Jarang digunakan di production modern

Publisher confirms:

• Lebih ringan
• Lebih scalable
• Direkomendasikan dibanding transaksi

Pola Penggunaan Publisher Confirms #

1️⃣ Synchronous Confirm #

Producer publish → tunggu confirm → lanjut.

Sederhana tetapi bisa menurunkan throughput.

2️⃣ Asynchronous Confirm #

Producer publish banyak message → handle confirm via callback.

Lebih efisien untuk high throughput.

3️⃣ Batch Confirm #

Publish beberapa message → tunggu confirm kolektif.

Tradeoff antara latency dan performa.

Tanpa Publisher Confirms: Risiko Nyata #

Jika tidak menggunakan confirm:

• Producer tidak tahu message diterima
• Broker crash → message hilang
• Tidak ada retry di sisi producer

Banyak sistem mengira mereka menggunakan at-least-once.

Padahal tanpa confirm, sisi producer sebenarnya mendekati at-most-once.

Hubungan dengan Delivery Guarantee #

Untuk mencapai at-least-once end-to-end:

Diperlukan:

• Publisher confirm (producer side)
• Manual ack (consumer side)

Tanpa confirm:

• Producer tidak memiliki jaminan publish sukses

Tanpa manual ack:

• Broker tidak memiliki jaminan process sukses

Delivery guarantee adalah kombinasi kedua sisi.

Dampak terhadap Throughput #

Publisher confirms menambah overhead:

• Round trip tambahan
• Tracking sequence number

Namun dengan asynchronous confirm:

• Dampak throughput bisa diminimalkan

Tradeoff antara reliability dan performa harus dipilih secara sadar.

Best Practice Production #

• Aktifkan publisher confirms untuk workload kritikal
• Gunakan asynchronous confirm untuk throughput tinggi
• Kombinasikan dengan persistent message
• Gunakan quorum queue untuk durability cluster
• Monitor confirm latency

Confirm latency yang meningkat bisa menjadi indikator overload.

Ringkasan #

Publisher confirms memastikan:

• Producer tahu message benar-benar diterima broker
• Mengurangi risiko silent data loss
• Memperkuat at-least-once delivery

Tanpa publisher confirm, delivery guarantee tidak lengkap.

Penutup #

Dalam sistem messaging, keberhasilan publish tidak boleh diasumsikan.

Ia harus dikonfirmasi.

Publisher confirms adalah jembatan antara niat producer dan kepastian broker.

Ia mungkin menambah sedikit latency.

Namun ia menghilangkan ketidakpastian yang jauh lebih mahal.

Karena dalam arsitektur yang matang, pesan tidak hanya dikirim.

Ia dipastikan sampai dengan aman.