Message Size #

RabbitMQ dirancang untuk mengirim pesan secara efisien.

Namun salah satu kesalahan desain yang sering terjadi adalah mengirim payload yang terlalu besar melalui queue.

Secara teknis, RabbitMQ memang bisa menerima message besar.

Tetapi secara arsitektural, itu bukan praktik yang sehat.

Artikel ini membahas mengapa ukuran message harus dikontrol, risiko jika diabaikan, dan strategi desain yang lebih tepat.

“Semakin besar pesan yang dikirim, semakin besar pula beban tersembunyi yang harus ditanggung sistem.”

Mengapa Message Size Penting? #

Ukuran message memengaruhi:

• Memory usage broker
• Disk I/O (jika persistent)
• Replication overhead (quorum queue)
• Network bandwidth
• Latency publish dan consume

Semakin besar payload:

• Semakin lama waktu transmit
• Semakin berat proses replikasi
• Semakin lambat recovery saat restart

Message size bukan hanya detail teknis kecil. Ia berdampak langsung pada stabilitas sistem.

Dampak Mengirim Payload Terlalu Besar #

1️⃣ Memory Pressure #

RabbitMQ menggunakan memory untuk:

• Buffering message
• Handling unacked message
• Flow control

Payload besar mempercepat memory watermark tercapai.

2️⃣ Disk I/O Membengkak #

Untuk persistent message atau quorum queue:

• Payload ditulis ke disk
• Direplikasi ke follower

Payload besar memperberat I/O dan memperlambat confirm.

3️⃣ Replication Cost pada Quorum Queue #

Quorum queue harus mereplikasi message ke mayoritas node.

Payload besar berarti:

• Network traffic besar
• Disk write besar di setiap node

Latency meningkat secara signifikan.

4️⃣ Recovery Lambat #

Jika broker restart dan memiliki backlog besar dengan payload besar:

• Waktu recovery meningkat
• Queue loading menjadi lambat

5️⃣ Retry & DLQ Menjadi Mahal #

Jika message besar masuk retry atau DLQ:

• Biaya penyimpanan meningkat
• Transfer ulang mahal

Batasan Resmi RabbitMQ #

RabbitMQ memiliki batas maksimal message size (default sekitar 128MB).

Namun:

Batas ini bukan rekomendasi desain.

Best practice umum production:

• Jaga message tetap kecil
• Idealnya < 1MB
• Lebih baik lagi beberapa KB

Ukuran kecil membantu throughput dan stabilitas.

Pola yang Lebih Sehat: Store Pointer, Bukan Payload #

Alih-alih mengirim file besar atau data blob melalui RabbitMQ:

Gunakan pola berikut:

1️⃣ Simpan data besar di:

• Object storage (S3, GCS, MinIO)
• Database

2️⃣ Kirim hanya referensi dalam message:

• File ID
• URL
• Resource key

Contoh payload ringan:

{
  "order_id": "12345",
  "invoice_file": "s3://bucket/invoice-12345.pdf"
}

Ini jauh lebih efisien.

Message Size dan Throughput #

Throughput sangat dipengaruhi oleh ukuran payload.

Contoh ilustratif:

• 10.000 message per detik @ 1KB
• 10.000 message per detik @ 1MB

Perbedaannya 1000x dalam bandwidth.

Message besar mengurangi message rate yang bisa diproses.

Message Size dan Backpressure #

Payload besar lebih cepat memicu:

• Memory watermark
• Disk alarm
• Flow control

Producer mungkin akan sering mengalami blocked connection.

Masalah terlihat seperti overload biasa, padahal akar masalahnya ukuran message.

Kapan Message Besar Masih Masuk Akal? #

Jarang, tetapi mungkin terjadi jika:

• Volume sangat rendah
• Tidak ada quorum replication
• Infrastruktur sangat kuat

Namun bahkan dalam kondisi tersebut, pola pointer tetap lebih direkomendasikan.

Best Practice dalam Mengontrol Message Size #

• Gunakan payload ringkas (JSON minimal)
• Hindari embed file binary
• Hindari base64 untuk file besar
• Gunakan compression jika perlu
• Simpan data besar di storage terpisah
• Monitor average message size

Ukuran message harus menjadi metric yang dipantau.

Perbandingan: Payload Besar vs Ringan #

Payload ringan membuat sistem lebih sehat.

Ringkasan #

Message size memengaruhi:

• Latency
• Throughput
• Reliability
• Backpressure
• Resource usage

RabbitMQ adalah transport layer.

Ia bukan media transfer file besar.

Penutup #

Dalam sistem messaging, pesan seharusnya membawa informasi — bukan beban.

Semakin besar payload, semakin besar biaya tersembunyi yang harus dibayar oleh:

• Disk
• Memory
• Network
• Cluster

Best practice bukan tentang memaksimalkan batas ukuran message.

Tetapi tentang meminimalkan beban agar sistem tetap ringan, cepat, dan stabil.

Karena dalam arsitektur RabbitMQ, efisiensi bukan hanya soal kecepatan.

Ia tentang menjaga sistem tetap sehat dalam jangka panjang.