RabbitMQ as Database #

Dalam praktik nyata, ada satu kesalahan arsitektural yang cukup sering terjadi:

Menggunakan RabbitMQ seolah-olah ia adalah database.

Karena RabbitMQ mampu:

• Menyimpan message di disk
• Memiliki durable queue
• Memiliki quorum replication

Sebagian orang berpikir:

“Kalau begitu, kenapa tidak kita jadikan saja sebagai storage utama?”

Inilah anti-pattern yang berbahaya.

Artikel ini membahas mengapa menggunakan RabbitMQ sebagai database adalah kesalahan desain, apa risikonya, dan bagaimana arsitektur yang seharusnya.

“Message broker menyimpan pesan untuk dikirim — bukan untuk menjadi sumber kebenaran jangka panjang.”

Mengapa Orang Tergoda Menggunakan RabbitMQ sebagai Database? #

Beberapa alasan umum:

• Queue bisa menyimpan message lama
• Quorum queue memiliki replication
• Persistent message ditulis ke disk
• Sudah ada cluster, tidak ingin tambah database lagi
• Ingin “simple architecture”

Secara permukaan, terlihat masuk akal.

Namun secara arsitektural, RabbitMQ tidak dirancang untuk menjadi data store permanen.

Perbedaan Filosofis: Broker vs Database #

RabbitMQ dirancang untuk:

• Message delivery
• Work distribution
• Asynchronous communication

Database dirancang untuk:

• Query fleksibel
• ACID transaction
• Indexing
• Long-term storage
• Consistent state management

Message broker dan database memiliki tujuan berbeda.

Masalah Jika RabbitMQ Dijadikan Database #

1️⃣ Tidak Ada Query Capability #

RabbitMQ tidak menyediakan:

• SQL
• Index
• Filter kompleks
• Join
• Aggregation

Anda tidak bisa bertanya:

“Ambil semua order dengan status pending selama 3 hari terakhir.”

Queue bukan query engine.

2️⃣ Retention Bukan Storage Strategy #

RabbitMQ tidak dirancang untuk menyimpan message tanpa batas.

• Queue besar akan meningkatkan memory pressure
• Disk I/O meningkat
• Recovery restart menjadi lambat

Quorum queue bukan pengganti database terdistribusi.

3️⃣ Replay Terbatas #

Setelah message di-ack:

• Message hilang

Tidak ada replay native seperti Kafka.

Jika message adalah satu-satunya sumber data dan sudah di-ack, data tersebut lenyap.

4️⃣ Recovery dan Snapshot Tidak Ada #

Database memiliki:

• Backup
• Restore
• Snapshot
• Point-in-time recovery

RabbitMQ tidak dirancang untuk skenario ini.

5️⃣ Observability dan Auditing Terbatas #

RabbitMQ tidak menyediakan:

• Versioned record
• Historical query
• Structured data indexing

Ia menyimpan blob message, bukan entitas bisnis terstruktur.

Dampak Nyata Anti-Pattern Ini #

Beberapa konsekuensi nyata:

• Queue membengkak karena dianggap storage permanen
• Restart broker menjadi sangat lama
• Memory watermark sering tercapai
• Flow control sering aktif
• Data sulit direkonstruksi
• Debugging menjadi sulit

Sistem terlihat berjalan — tetapi rapuh.

Kapan RabbitMQ Boleh Menyimpan Data? #

RabbitMQ memang menyimpan message, tetapi dalam konteks:

• Buffer sementara
• In-flight work
• Retry
• Event transit

Ia adalah transport layer, bukan source of truth.

Arsitektur yang Benar #

Pendekatan yang sehat:

1️⃣ Simpan state bisnis di database 2️⃣ Gunakan RabbitMQ untuk mengirim event atau task 3️⃣ Pastikan message bersifat stateless atau self-contained 4️⃣ Jangan bergantung pada queue sebagai storage utama

Contoh:

User Service → Simpan ke Database → Publish event ke RabbitMQ

Worker → Proses message → Update database

Database tetap menjadi sumber kebenaran.

Perbandingan Singkat #

Menggunakan RabbitMQ sebagai database melanggar prinsip separation of concern.

Kasus yang Terlihat Seperti Database Tapi Bukan #

Kadang orang menggunakan:

• Single consumer
• Tanpa ack
• Queue sangat panjang

Untuk menyimpan “event history”.

Ini tetap bukan database.

Jika consumer crash atau config berubah, data bisa hilang.

Hubungan dengan Kafka #

Sebagian orang membandingkan:

“Kafka bisa menyimpan data lama, kenapa RabbitMQ tidak?”

Kafka memang dirancang sebagai distributed log dengan retention policy.

RabbitMQ bukan log store.

Mencoba menjadikannya log store adalah kesalahan desain.

Best Practice #

• Gunakan database untuk state
• Gunakan RabbitMQ untuk komunikasi
• Jangan simpan message tanpa batas
• Monitor queue depth
• Dokumentasikan data ownership

Arsitektur yang bersih memisahkan transport dan storage.

Ringkasan #

RabbitMQ adalah:

• Message broker
• Transport layer
• Work distribution system

Ia bukan:

• Database
• Event store
• Query engine
• Long-term storage

Penutup #

Menggunakan RabbitMQ sebagai database mungkin terlihat praktis di awal.

Namun dalam jangka panjang, ia akan menciptakan sistem yang sulit di-maintain, sulit di-scale, dan berisiko kehilangan data.

Message broker dirancang untuk memindahkan data. Database dirancang untuk menyimpan data.

Mencampur keduanya bukanlah inovasi.

Ia adalah anti-pattern.

Dan dalam arsitektur sistem terdistribusi, anti-pattern sering kali baru terasa dampaknya ketika sistem sudah terlalu besar untuk diperbaiki dengan mudah.