Metadata, State & Message Storage #

Banyak engineer menggunakan RabbitMQ tanpa pernah memikirkan satu hal krusial:

Apa sebenarnya yang disimpan oleh RabbitMQ?

Apakah hanya message? Apakah metadata juga direplikasi? Bagaimana state koneksi dikelola?

Memahami metadata dan state dalam RabbitMQ adalah fondasi untuk memahami:

• Cluster behavior
• Fault tolerance
• Durability
• Recovery setelah crash

Artikel ini membedah secara spesifik bagaimana RabbitMQ mengelola metadata dan state.

“Dalam sistem terdistribusi, bukan hanya data yang penting — tetapi juga siapa yang tahu tentang data itu, dan di mana ia disimpan.”

Apa Itu Metadata dalam RabbitMQ? #

Metadata adalah informasi tentang struktur sistem messaging, bukan isi pesannya.

Contoh metadata:

• Exchange
• Queue definition
• Binding
• User & permission
• Virtual host (vhost)
• Policy

Metadata menentukan bagaimana pesan akan diproses dan dirutekan.

Tanpa metadata, message tidak tahu harus ke mana.

Apa Itu State dalam RabbitMQ? #

State adalah kondisi runtime yang berubah seiring waktu.

Contoh state:

• Message dalam queue
• Status consumer
• Unacknowledged message
• Connection dan channel
• Offset atau delivery tag

State bersifat dinamis.

Metadata relatif statis.

Perbedaan Metadata dan Message Data #

Penting untuk memisahkan tiga hal:

1. Metadata
2. Message data
3. Runtime state

1. Diagram Konseptual Metadata vs Message #

+---------------------------+
|        Metadata           |
|  Exchange                 |
|  Queue definition         |
|  Binding                  |
+---------------------------+
            |
            v
+---------------------------+
|       Message Data        |
|  Payload                  |
|  Header                   |
+---------------------------+
            |
            v
+---------------------------+
|       Runtime State       |
|  Unacked message          |
|  Active consumer          |
|  Channel state            |
+---------------------------+

Ketiganya memiliki perlakuan berbeda dalam cluster dan persistence.

Bagaimana Metadata Disimpan? #

Dalam RabbitMQ cluster:

• Metadata direplikasi ke semua node
• Semua node mengetahui exchange dan queue yang ada

Ini berarti:

• Client bisa connect ke node mana saja
• Exchange tetap dikenali

Namun metadata bukan berarti message data juga direplikasi.

Ini sering disalahpahami.

Bagaimana Message Data Disimpan? #

Message storage tergantung tipe queue.

Classic Queue #

• Message berada di satu node
• Jika node mati, queue tidak tersedia

Quorum Queue #

• Message direplikasi ke beberapa node
• Menggunakan mekanisme consensus (Raft)
• Majority diperlukan untuk tetap aktif

Pemilihan tipe queue menentukan behavior fault tolerance.

Runtime State: Bagian yang Paling Rentan #

Runtime state seperti:

• Unacknowledged message
• Connection state

Biasanya berada di memory.

Jika node crash:

• Connection hilang
• Unacked message akan di-requeue

Ini bagian dari mekanisme at-least-once delivery.

Metadata dalam Cluster #

2. Diagram Replikasi Metadata #

+-----------+     +-----------+     +-----------+
|  Node 1   |<--->|  Node 2   |<--->|  Node 3   |
| Metadata  |     | Metadata  |     | Metadata  |
+-----------+     +-----------+     +-----------+

Semua node menyimpan definisi exchange dan queue.

Namun message data belum tentu ada di semua node.

Implikasi terhadap Fault Tolerance #

Karena metadata direplikasi:

• Struktur tetap konsisten
• Routing tetap dikenal

Namun jika queue classic berada di node yang mati:

• Message tidak dapat diakses

Karena itu untuk sistem mission-critical:

• Gunakan quorum queue
• Pahami lokasi leader dan replica

Recovery Setelah Crash #

Saat node restart:

Jika Queue Durable dan Message Persistent #

• Metadata dimuat kembali
• Message di-recover dari disk

Jika Queue Non-Durable #

• Queue hilang
• Message hilang

Perbedaan ini penting dalam desain durability.

Kesalahan Umum #

Mengira Cluster Otomatis Replikasi Semua Data #

Cluster hanya menjamin metadata tersebar.

Message replication tergantung tipe queue.

Tidak Memahami Unacked Message #

Jika consumer tidak ack:

• Message tetap dalam state unacked
• Jika connection putus, message di-requeue

Ini sering menyebabkan duplicate processing jika tidak idempotent.

Ringkasan #

Penutup #

RabbitMQ bukan hanya sistem pengiriman pesan.

Ia adalah sistem yang mengelola:

• Metadata struktur messaging
• Message data
• Runtime state

Memahami perbedaan ketiganya adalah kunci untuk:

• Mendesain cluster yang benar
• Menghindari kehilangan data
• Mengantisipasi behavior saat crash

Karena dalam sistem terdistribusi, memahami apa yang disimpan dan di mana ia berada jauh lebih penting daripada sekadar mengetahui cara publish dan consume.