Publishing #

Dalam RabbitMQ, message lifecycle tidak dimulai ketika message masuk ke queue.

Ia dimulai saat producer melakukan publish ke exchange.

Tahap publishing adalah fondasi dari:

• Reliability
• Routing
• Durability
• Delivery guarantee

Kesalahan desain di tahap ini dapat menyebabkan:

• Message hilang
• Routing salah
• Silent drop
• Inconsistency downstream

Artikel ini membahas tahap publishing sebagai bagian pertama dari message lifecycle dalam RabbitMQ.

“Setiap pesan memiliki perjalanan. Dan perjalanan itu dimulai pada satu momen krusial: saat ia dipublish.”

Apa Itu Publishing? #

Publishing adalah proses ketika producer:

1. Membuat message
2. Menentukan exchange
3. Menentukan routing key
4. Mengirim message ke broker

Secara teknis, producer memanggil operasi:

basic.publish

Namun di balik operasi sederhana ini, ada beberapa layer mekanisme penting.

Tahap Internal Saat Publishing #

1. Diagram Lifecycle Tahap Publishing #

Producer
   |
   | basic.publish(exchange, routing_key)
   v
Broker menerima message
   |
   | Validasi exchange
   | Evaluasi binding
   v
Routing ke queue

Namun sebelum routing terjadi, ada beberapa keputusan sistem yang penting.

Validasi Exchange #

Saat publish terjadi:

• Broker memeriksa apakah exchange ada
• Jika tidak ada → channel error

Karena itu best practice:

• Exchange dideklarasikan sebelum publish
• Gunakan idempotent declaration saat startup service

Routing Key Evaluation #

Broker kemudian:

• Mengevaluasi routing key
• Mencocokkan dengan binding pada exchange

Jika tidak ada binding yang cocok:

• Message bisa dibuang
• Atau dikembalikan jika mandatory=true

Inilah salah satu titik rawan silent drop.

Mandatory Flag dan Return #

Producer dapat mengaktifkan:

mandatory = true

Jika message tidak dapat dirutekan ke queue manapun:

• Broker mengembalikan message ke producer

Tanpa mandatory:

• Message hilang tanpa error

Dalam production system, mandatory sering direkomendasikan.

Publisher Confirm dan Durability #

Publish tidak otomatis berarti message sudah aman.

Jika publisher confirm diaktifkan:

1. Broker menerima message
2. Broker memastikan message telah disimpan (jika persistent)
3. Broker mengirim confirm ke producer

Tanpa confirm:

• Producer tidak tahu apakah message benar-benar tersimpan

2. Diagram Publisher Confirm #

Producer  → publish →  Broker
Producer  ← confirm ←  Broker

Confirm menjadi bagian penting dari reliability lifecycle.

Persistent vs Transient Message Saat Publish #

Saat publish, producer menentukan:

• delivery_mode = 1 (transient)
• delivery_mode = 2 (persistent)

Jika ingin durability:

• Queue harus durable
• Message harus persistent
• Publisher confirm sebaiknya aktif

Publishing adalah momen di mana durability diputuskan.

Backpressure dan Flow Control #

Saat publish terjadi dalam volume tinggi:

• Broker bisa mencapai memory watermark
• Flow control aktif
• Producer diblokir sementara

Artinya publishing bukan operasi tanpa batas.

Sistem harus siap menghadapi backpressure.

Error yang Bisa Terjadi Saat Publish #

Beberapa kemungkinan error:

Exchange Tidak Ada #

Channel akan ditutup oleh broker.

Message Tidak Dirutekan #

Jika mandatory=false → silent drop.

Broker Overload #

Flow control atau connection block terjadi.

Disk Lambat (Quorum Queue) #

Publish latency meningkat karena replication.

Publishing dalam Cluster dan Quorum Queue #

Jika menggunakan quorum queue:

• Publish diterima oleh leader
• Direplikasi ke follower
• Commit terjadi setelah mayoritas setuju

Artinya publishing latency dipengaruhi oleh:

• Network
• Disk
• Jumlah node cluster

Lifecycle publish di cluster lebih kompleks dibanding single node.

Best Practice Production #

Selalu Deklarasikan Exchange Secara Eksplisit #

Hindari bergantung pada default exchange tanpa kontrol.

Gunakan Publisher Confirm untuk Data Kritis #

Tanpa confirm, durability tidak terjamin.

Gunakan Mandatory Flag #

Cegah silent drop.

Monitor Publish Rate dan Latency #

Pantau:

• Confirm latency
• Unroutable message
• Flow control status

Ringkasan #

Penutup #

Publishing adalah langkah pertama dalam perjalanan sebuah message.

Pada tahap inilah ditentukan:

• Apakah message akan sampai
• Apakah ia aman dari crash
• Apakah ia dirutekan dengan benar

Kesalahan kecil dalam konfigurasi publish dapat berdampak besar pada reliability sistem.

Dalam lifecycle RabbitMQ, publishing bukan sekadar mengirim data — ia adalah titik awal dari seluruh mekanisme keandalan yang mengikuti setelahnya.