Belajar RabbitMQ - Message Properties & Headers

#Pendahuluan

Sejauh ini kita memakai pesan hanya sebagai body mentah. Padahal, sebuah pesan AMQP membawa properties — metadata terstruktur yang memberitahu broker dan consumer bagaimana pesan harus diperlakukan. Ada 14 properti standar dalam AMQP 0-9-1, dan masing-masing punya peran spesifik.

Beberapa properties menentukan perilaku broker: delivery_mode menandai pesan persistent, expiration menetapkan TTL, dan priority mengatur urutan antrean. Beberapa lainnya adalah metadata bisnis: correlation_id, message_id, app_id, dan timestamp. Memahami seluruhnya membuat kalian mampu merancang pesan yang informatif tanpa membocorkan detail ke body.

Selain properties, episode ini membahas custom headers untuk metadata bebas, serta persoalan ukuran pesan: batas bawaan RabbitMQ, strategi menangani payload besar, dan kompresi. Ini adalah bekal penting karena ukuran pesan sering kali jadi biang masalah performa di produksi.

#Standard Message Properties

#Properties untuk Perilaku Broker

Empat properti yang paling sering memengaruhi cara broker memproses pesan:

• delivery_mode — 1 untuk transient, 2 untuk persistent (ditulis ke disk).
• priority — 0 sampai 255, menentukan urutan pesan dalam priority queue.
• expiration — TTL per pesan dalam milidetik; lewat batas, pesan dianggap mati.
• type — nama tipe pesan, misalnya order.created, berguna untuk konsumen yang menangani banyak tipe.

Publish dengan properties lengkap

properties = pika.BasicProperties(
    content_type="application/json",
    delivery_mode=2,
    priority=5,
    expiration="60000",
    type="order.created",
)
channel.basic_publish(exchange="orders", routing_key="order.created",
                      body=b'{"id": "A-001"}', properties=properties)

Pesan di atas persistent, berprioritas 5, dan berakhir setelah 60 detik.

#Properties untuk Tracing dan Routing

• correlation_id — memasangkan request dengan response (dipakai di episode 8).
• message_id — ID unik pesan untuk deduplication dan tracing.
• timestamp — waktu pesan dibuat.
• reply_to — nama queue untuk response.
• user_id — nama user yang mem-publish; jika diisi, broker memvalidasinya.
• app_id — identitas aplikasi publisher, berguna untuk observability.

Best practice: isi message_id dan app_id di setiap pesan. Keduanya sangat membantu saat menelusuri perjalanan pesan di sistem terdistribusi.

#Custom Headers

#Menambahkan Metadata ke Pesan

Selain properties standar, kalian bisa menambahkan headers bebas — pasangan key-value apa pun yang dibawa sebagai properti headers. Ini tempat untuk metadata bisnis seperti tenant ID, region asal, atau versi schema:

Menambahkan custom headers

properties = pika.BasicProperties(
    headers={
        "tenant_id": "acme",
        "region": "ap-southeast-1",
        "schema_version": "v2",
    }
)
channel.basic_publish(exchange="orders", routing_key="order.created",
                      body=b'{}', properties=properties)

Headers di atas bisa dibaca consumer tanpa mem-parsing body, dan bisa dipakai untuk routing headers exchange seperti di episode 7.

#Use Cases Custom Headers

Header berguna untuk: routing berbasis metadata, filtering di consumer, observability (trace id), dan evolusi schema — consumer lama bisa memeriksa schema_version sebelum mem-parsing body. Namun jangan berlebihan: header besar ikut menambah ukuran pesan dan memperlambat broker.

#Message Size Considerations

#Batas Ukuran Pesan

Secara default RabbitMQ menerima pesan hingga 128 MB (max_message_size). Setel ulang di rabbitmq.conf jika perlu:

max_message_size = 52428800

Nilai di atas membatasi pesan hingga 50 MB. Perlu diingat: pesan raksasa menyedot memori saat di-buffer, dan queue store menulisnya lebih lambat.

#Strategi Pesan Besar dan Chunking

Untuk payload besar, jangan kirim semuanya dalam satu pesan. Pecah menjadi chunk dengan urutan dan identitas:

• Kirim metadata di header: total chunk, nomor chunk, dan message id.
• Consumer merakit kembali setelah semua chunk tiba.
• Jika tidak ada consumer yang butuh potongan, alihkan ke object storage (S3) dan kirim hanya referensi URL lewat broker.

#Kompresi Payload

Kompresi bisa menekan ukuran body secara signifikan untuk data teks. Tandai dengan header agar consumer tahu formatnya:

Kompresi gzip dan tanda di header

import gzip, json
 
body = json.dumps({"orders": list(range(1000))}).encode()
compressed = gzip.compress(body)
 
properties = pika.BasicProperties(
    headers={"content-encoding": "gzip"},
)
channel.basic_publish(exchange="", routing_key="data_queue",
                      body=compressed, properties=properties)

Perintah gzip.compress mengompres body sebelum dikirim, dan consumer menandai penanganan sesuai header content-encoding.

#Penutup

Di episode 9 ini kalian sudah memahami seluruh properties standar AMQP, menambahkan custom headers untuk metadata bisnis dan observability, serta menyusun strategi untuk pesan besar: batas ukuran, chunking, dan kompresi payload.

Inti yang harus dibawa pulang:

• delivery_mode=2 menandai pesan persistent.
• priority dan expiration mengubah perilaku broker.
• correlation_id dan message_id penting untuk tracing dan RPC.
• app_id dan timestamp membantu observability lintas layanan.
• Custom headers menyimpan metadata tanpa menyentuh body.
• Batas pesan default 128 MB; atur ulang dengan max_message_size.
• Pesan besar dipecah jadi chunk atau diganti referensi object storage.
• Kompresi menekan payload besar dengan tanda di header.

Di episode 10 selanjutnya kita akan membahas queue features dan configuration — perbandingan classic queues, quorum queues, stream queues, dan priority queues, lengkap dengan argumen seperti max length, TTL, overflow behavior, serta tipe deklarasi durable, exclusive, dan auto-delete. Pilihan tipe queue ini menentukan keandalan dan performa sistem kalian!