Producer #

Dalam arsitektur RabbitMQ, producer adalah titik awal dari seluruh aliran data.

Tanpa producer, tidak ada message. Tanpa message, tidak ada event. Tanpa event, tidak ada sistem asynchronous.

Namun producer bukan sekadar “pengirim pesan”.

Cara producer mengirim pesan menentukan:

• Reliability
• Delivery guarantee
• Ordering
• Throughput
• Beban broker

Artikel ini membahas producer secara mendalam dalam konteks RabbitMQ production system.

“Setiap sistem event-driven dimulai dari satu aksi kecil: seseorang atau sesuatu memutuskan untuk mengirim pesan.”

Apa Itu Producer? #

Producer adalah aplikasi atau komponen yang:

• Membuat message
• Mengirimkannya ke exchange di RabbitMQ

Penting dipahami:

Producer tidak mengirim pesan langsung ke queue.

Producer selalu mengirim ke:

• Exchange

Exchange yang akan menentukan ke queue mana pesan dirutekan.

Alur Kerja Producer #

1. Diagram Alur Producer ke Exchange #

Producer
    |
    | publish(message, routing_key)
    v
Exchange
    |
    v
Queue

Langkah teknisnya:

1. Producer membuka connection ke broker
2. Membuka channel
3. Mengirim pesan ke exchange dengan routing key
4. Broker menerima dan merutekan

Producer tidak tahu queue mana yang menerima pesan.

Connection dan Channel #

Dalam RabbitMQ:

• Connection = TCP connection ke broker
• Channel = virtual connection di dalam connection

Best practice:

• Jangan buka connection per message
• Gunakan connection pooling
• Gunakan channel reuse

Connection mahal. Channel relatif murah.

Desain producer yang buruk sering menyebabkan bottleneck di sini.

Struktur Message yang Dikirim Producer #

Sebuah message terdiri dari:

• Payload (body)
• Header
• Properties

Contoh properti penting:

• delivery_mode (persistent atau transient)
• content_type
• correlation_id
• message_id
• timestamp

Producer bertanggung jawab menentukan metadata ini.

Publisher Confirm: Jaminan Pesan Sampai ke Broker #

Secara default, publish tidak menjamin pesan benar-benar tersimpan.

Producer bisa mengaktifkan:

• Publisher confirm mode

2. Diagram Publisher Confirm #

Producer  ---- publish ---->  Broker
Producer  <--- confirm ------  Broker

Dengan confirm:

• Producer mendapat acknowledgement dari broker
• Bisa retry jika gagal

Tanpa confirm, pesan bisa hilang jika broker crash sebelum commit.

Untuk sistem critical, publisher confirm hampir wajib.

Mandatory Flag dan Return Message #

Producer bisa mengatur flag:

• mandatory = true

Jika message tidak dapat dirutekan ke queue manapun:

• Broker akan mengembalikan message ke producer

Tanpa mandatory:

• Message bisa silently dropped

Ini sering diabaikan dan menyebabkan kehilangan data tanpa disadari.

Producer dan Delivery Mode #

Producer menentukan apakah pesan:

• Transient (non-persistent)
• Persistent

Jika ingin durability:

• Queue harus durable
• Message harus persistent

Keduanya harus benar.

Jika salah satu tidak, durability tidak terjamin.

Throughput vs Reliability Tradeoff #

Producer dapat dioptimalkan untuk:

• Throughput tinggi
• Atau reliability tinggi

High Throughput Mode #

• Tanpa publisher confirm
• Batch publish
• Transient message

High Reliability Mode #

• Publisher confirm aktif
• Persistent message
• Retry logic

Tradeoff harus disesuaikan dengan kebutuhan bisnis.

Idempotency dan Duplicate Message #

Karena RabbitMQ default-nya at-least-once:

• Producer bisa retry publish
• Broker bisa mengirim ulang

Consumer harus idempotent.

Namun producer juga bisa membantu dengan:

• message_id unik
• correlation_id

Ini membantu deduplikasi di downstream.

Kesalahan Umum pada Producer #

Membuka Connection per Request #

Menyebabkan:

• Overhead TCP
• Latency tinggi
• Resource exhaustion

Tidak Menggunakan Publisher Confirm #

Risiko kehilangan pesan saat crash.

Tidak Menggunakan Mandatory Flag #

Message hilang tanpa error.

Tidak Memikirkan Backpressure #

Jika broker memory penuh:

• Flow control aktif
• Producer bisa diblokir

Producer harus siap menangani situasi ini.

Ringkasan #

Penutup #

Producer adalah pintu masuk semua pesan ke dalam sistem RabbitMQ.

Desain producer yang baik menentukan:

• Apakah pesan benar-benar sampai
• Apakah sistem tahan terhadap crash
• Apakah throughput optimal

RabbitMQ tidak bisa menjamin reliability sendirian.

Producer harus didesain dengan kesadaran penuh terhadap:

• Confirm
• Durability
• Retry
• Backpressure

Karena dalam sistem messaging, kesalahan paling mahal sering terjadi di titik awal: saat pesan pertama kali dikirim.