RabbitMQ as Database #

RabbitMQ merupakan alat yang sangat andal untuk mengalirkan pesan secara cepat dan efisien antar-layanan. Namun, kemampuannya untuk menulis pesan ke disk (persistent messages), mereplikasi data ke beberapa node (quorum queues), serta mempertahankan pesan di dalam antrean (queues) dalam jangka waktu lama sering kali memicu kesalahpahaman arsitektural yang fatal. Banyak tim developer, terutama yang baru mengadopsi pola komunikasi asinkron, tergoda untuk memperlakukan RabbitMQ seolah-olah ia adalah database utama. Mereka berasumsi bahwa selama pesan berada di dalam antrean yang durable, data mereka aman dan dapat diakses kapan saja layaknya baris tabel database.

Pendekatan ini adalah salah satu anti-pattern paling berbahaya dalam arsitektur sistem terdistribusi. Menjadikan message broker sebagai tempat penyimpanan data jangka panjang (long-term data store) bukan hanya menurunkan performa sistem secara drastis, melainkan juga membahayakan integritas data itu sendiri. Artikel ini akan membedah secara mendalam mengapa memperlakukan RabbitMQ sebagai database adalah kesalahan desain yang mahal, apa saja konsekuensi teknis di balik kap mesinnya, serta bagaimana kita seharusnya merancang arsitektur penyimpanan data yang benar menggunakan pola Transactional Outbox.

Mengapa Developer Tergoda Menggunakan RabbitMQ sebagai Database? #

Dalam fase awal pengembangan aplikasi, kecepatan implementasi sering kali menjadi prioritas utama. Ketika kita membutuhkan tempat untuk menyimpan log aktivitas, riwayat transaksi, atau jejak audit (audit trail), mendirikan database baru (baik SQL maupun NoSQL) dirasa menambah beban infrastruktur dan kompleksitas kode. Di sinilah godaan menggunakan antrean RabbitMQ muncul.

Beberapa faktor yang biasanya melatarbelakangi keputusan buruk ini antara lain:

1. Durable Queue dan Persistent Message: Fitur RabbitMQ yang memungkinkan antrean tetap bertahan setelah broker di-restart (durable) dan pesan ditulis ke disk (persistent) membuat developer merasa data mereka memiliki jaminan keamanan setara dengan penyimpanan database.
2. Quorum Queues: Adanya replikasi konsensus berbasis algoritma Raft pada Quorum Queues memberikan ilusi ketersediaan tinggi (high availability) dan toleransi kegagalan (fault tolerance) yang setara dengan klaster database terdistribusi seperti MongoDB atau Cassandra.
3. Kemudahan Akses: Developer berpikir bahwa dengan menumpuk pesan di antrean tanpa mengirimkan konfirmasi penerimaan (acknowledgement atau ACK), pesan tersebut akan tetap tersimpan di sana dan dapat dibaca oleh worker lain sewaktu-waktu.
4. Keengganan Mengelola State: Banyak developer ingin menghindari kerumitan sinkronisasi state antara database dan broker pesan, sehingga mereka memutuskan untuk menjadikan antrean sebagai satu-satunya sumber kebenaran (single source of truth).

Meskipun terlihat praktis pada skala kecil, asumsi-asumsi di atas mengabaikan prinsip dasar dari desain message broker. RabbitMQ dirancang dari bawah ke atas sebagai sistem pemrosesan pesan transient (sementara), bukan sebagai mesin penyimpanan data kekal.

Perbedaan Filosofis Fundamental: Broker vs Database #

Untuk memahami mengapa anti-pattern ini sangat merusak, kita harus meninjau perbedaan filosofis yang mendasar antara message broker dan database dari sudut pandang arsitektur perangkat lunak.

Filosofi Destructive Read pada RabbitMQ adalah kunci efisiensinya. Antrean RabbitMQ bekerja paling optimal ketika ukurannya mendekati nol. Artinya, setiap pesan yang masuk harus segera ditarik oleh konsumen, diproses, dan dihapus dari memori broker. Sebaliknya, database dirancang untuk menampung akumulasi data yang terus bertambah dari waktu ke waktu dan menyediakan mekanisme pencarian indeks yang cepat untuk memanggil data yang spesifik secara acak.

Anatomi Bahaya Menyimpan Pesan Jangka Panjang di RabbitMQ #

Ketika kita melanggar batas filosofis di atas dan membiarkan jutaan pesan menumpuk di antrean RabbitMQ untuk jangka panjang, kita sedang memicu reaksi berantai yang akan menurunkan performa seluruh klaster broker. Berikut adalah rincian teknis mengenai apa yang terjadi di dalam RabbitMQ:

1. Konsumsi RAM Broker yang Melonjak (Erlang GC Overhead) #

RabbitMQ ditulis menggunakan bahasa pemrograman Erlang dan berjalan di atas Erlang BEAM Virtual Machine. Untuk setiap pesan yang mengantre, RabbitMQ menyimpan metadata pesan tersebut (seperti ID pesan, posisi indeks, dan status pengiriman) di dalam memori RAM agar broker dapat mengalirkannya secara instan saat konsumen memintanya.

Jika kita membiarkan jutaan pesan menumpuk di satu antrean, memori RAM yang digunakan untuk mengelola indeks ini akan membengkak secara eksponensial. Erlang VM mengandalkan mekanisme Garbage Collection (GC) per proses. Ketika antrean menjadi sangat panjang, proses GC akan membutuhkan waktu lebih lama dan memakan siklus CPU yang besar hanya untuk memindai memori, yang pada akhirnya memicu latensi tinggi bagi proses publikasi pesan lainnya.

2. Disk Paging Slowdown (High Memory Watermark) #

Untuk mencegah kehabisan memori RAM, RabbitMQ memiliki mekanisme pengaman bernama High Memory Watermark. Secara default, batas ini disetel sebesar 40% dari total RAM yang tersedia pada mesin. Jika konsumsi memori broker melampaui batas ini akibat menumpuknya metadata antrean:

1. RabbitMQ akan membekukan seluruh koneksi produsen (block publishers). Ini adalah bentuk flow control untuk menghentikan laju pesan baru masuk.
2. Erlang VM akan mulai melakukan proses paging ke disk. Seluruh isi pesan yang awalnya berada di RAM akan ditulis paksa ke penyimpanan piringan fisik (disk) untuk membebaskan ruang memori.

Proses paging ini berjalan sangat lambat karena melibatkan operasi I/O disk yang sinkron. Akibatnya, throughput broker akan anjlok secara drastis, dan sistem kita yang mengandalkan RabbitMQ untuk komunikasi real-time akan mengalami latency cascade (kegagalan latensi beruntun).

3. Startup Recovery Time yang Sangat Lambat #

Jika broker RabbitMQ mengalami crash atau sengaja di-restart untuk keperluan pemeliharaan (maintenance), dan di dalamnya terdapat antrean yang menampung jutaan pesan persisten:

• Saat startup, RabbitMQ harus membaca kembali seluruh berkas indeks pesan dari disk ke memori RAM untuk merekonstruksi status antrean.
• Proses rekonstruksi indeks ini dapat memakan waktu puluhan menit hingga berjam-jam, tergantung pada kecepatan disk dan jumlah pesan.
• Selama proses pemulihan indeks ini berlangsung, broker tidak dapat melayani koneksi baru, yang mengakibatkan downtime sistem terdistribusi kita menjadi sangat panjang.

4. Write Amplification pada Quorum Queues #

Jika kita menggunakan Quorum Queues untuk menyimpan pesan jangka panjang dalam jumlah besar, situasinya akan jauh lebih buruk. Quorum Queues mengandalkan log replikasi Raft yang ditulis secara sekuensial ke disk pada setiap node klaster.

Setiap pesan yang tidak di-ACK akan terus berada di dalam log Raft yang aktif. Hal ini mencegah broker melakukan log truncation (pemotongan log historis yang tidak diperlukan). Akibatnya, disk space pada seluruh node klaster akan membengkak dengan cepat akibat efek write amplification, dan performa sinkronisasi antar-node klaster akan melambat karena ukuran metadata konsensus Raft yang terlalu besar.

Mengapa RabbitMQ Tidak Memiliki Kapabilitas Kunci Database? #

Selain masalah performa internal broker, dari sisi fungsionalitas aplikasi, RabbitMQ sama sekali tidak memiliki fitur-fitur dasar yang wajib dimiliki oleh sebuah sistem penyimpanan database:

1. Tidak Ada Kemampuan Query Acak (Random Query) #

Di dalam database, kita dapat dengan mudah mencari data tertentu menggunakan kueri SQL seperti:

SELECT * FROM orders WHERE user_id = 456 AND status = 'failed' ORDER BY created_at DESC;

Di RabbitMQ, kita tidak bisa melakukan kueri acak seperti itu. Satu-satunya cara untuk membaca pesan adalah dengan mengonsumsinya secara sekuensial dari urutan terdepan antrean (FIFO). Kita tidak bisa meminta broker untuk “ambil pesan nomor 5.000 di tengah antrean tanpa mengambil pesan 1 sampai 4.999”. Mencoba menyiasati ini dengan mengambil semua pesan, memfilternya di aplikasi, dan mengirimkan kembali (requeue) pesan yang tidak cocok ke broker adalah bencana performa yang sangat besar.

2. Tidak Ada Indeks Dinamis (Indexing) #

Database menggunakan struktur B-Tree atau LSM-Tree untuk mengindeks kolom data sehingga pencarian kueri dapat berjalan dalam waktu konstan atau logaritmik. RabbitMQ tidak memiliki konsep indeks kolom. Semua payload pesan disimpan sebagai raw binary blob. Broker tidak tahu dan tidak peduli apa isi di dalam pesan tersebut (apakah JSON, XML, atau Protocol Buffers), sehingga tidak ada cara bagi broker untuk mengindeks properti internal payload untuk kueri cepat.

3. Ketiadaan Backup dan Point-in-Time Recovery (PITR) #

Database produksi memiliki mekanisme backup berkala, replikasi read-only replica, dan pencatatan Write-Ahead Log (WAL) untuk memulihkan data ke detik tertentu sebelum terjadi insiden (Point-in-Time Recovery). RabbitMQ tidak dirancang untuk backup parsial data antrean. Jika sebuah antrean rusak atau terhapus secara tidak sengaja melalui Management UI oleh administrator, seluruh data di dalamnya akan musnah seketika dan tidak dapat dipulihkan secara parsial melalui mekanisme backup standar database.

Pola Arsitektur yang Benar: Separation of Concerns #

Untuk menghindari jebakan arsitektural ini, kita harus menerapkan prinsip Separation of Concerns (Pemisahan Tanggung Jawab). Kita harus memperlakukan RabbitMQ murni sebagai transport layer untuk mengirimkan instruksi atau memberi tahu adanya perubahan state (event notification), sementara database tetap bertindak sebagai storage layer yang menjadi satu-satunya sumber kebenaran data (source of truth).

Pola desain standar industri yang memecahkan masalah integrasi antara database dan broker pesan secara aman adalah Transactional Outbox Pattern.

Bagaimana Transactional Outbox Pattern Bekerja? #

Alih-alih mempublikasikan pesan ke RabbitMQ secara langsung di tengah-tengah proses bisnis aplikasi (yang berisiko gagal jika broker down atau koneksi terputus), kita melakukan langkah-langkah berikut:

1. Tulis ke Tabel Utama & Tabel Outbox: Di dalam satu transaksi database yang ACID (aman secara transaksional), kita menyimpan data bisnis utama (misalnya tabel orders) dan secara bersamaan menulis metadata event yang ingin dikirim ke sebuah tabel khusus bernama outbox di database yang sama.
2. Commit Transaksi: Transaksi database di-commit. Karena kedua penulisan berada dalam transaksi yang sama, kita dijamin secara mutlak bahwa data bisnis dan event outbox akan tersimpan bersama, atau keduanya gagal sama sekali (all-or-nothing).
3. Outbox Publisher: Sebuah proses latar belakang independen (Outbox Publisher atau Message Relay) secara berkala membaca tabel outbox (menggunakan teknik polling kueri indeks atau CDC - Change Data Capture), mempublikasikan pesan-pesan tersebut ke RabbitMQ, dan menghapus atau menandai pesan outbox sebagai “sent” setelah menerima konfirmasi publikasi (Publisher Confirms) dari RabbitMQ.
4. Consumer Processing: Konsumen membaca pesan dari RabbitMQ, memprosesnya, memperbarui database lokal miliknya sendiri, dan mengirimkan ACK ke RabbitMQ untuk menghapus pesan tersebut dari antrean secepat mungkin.

Dengan pola ini, RabbitMQ tidak pernah menyimpan data backlog historis. Antrean RabbitMQ hanya berfungsi sebagai pipa penyalur sementara yang dinamis.

Hubungan Arsitektur Aliran Data: Outbox Pattern #

Diagram berikut mengilustrasikan alur kerja penulisan transaksional menggunakan Transactional Outbox Pattern, yang memisahkan media penyimpanan state permanen (Database) dengan media pengaliran pesan sementara (RabbitMQ).

flowchart TD
    subgraph Aplikasi Produsen ["Aplikasi Produsen (Microservice A)"]
        A[Logika Bisnis] -->|1. Mulai Transaksi ACID| B[(Database Utama)]
        A -->|2. Tulis Tabel Bisnis e.g. Orders| B
        A -->|3. Tulis Tabel Outbox e.g. Outbox| B
        A -->|4. Commit Transaksi| B
    end

    subgraph Relay ["Proses Relay (Outbox Publisher)"]
        C[Outbox Publisher Loop] -->|5. Polling / CDC data unsent| B
        C -->|6. Kirim Event| D[RabbitMQ Exchange]
        D -->|7. Rutekan Pesan| E[RabbitMQ Queue]
        D -. "8. Publisher Confirm" .-> C
        C -->|9. Tandai Outbox Telah Terkirim| B
    end

    subgraph Aplikasi Konsumen ["Aplikasi Konsumen (Microservice B)"]
        F[Consumer Worker] -->|10. Tarik Pesan FIFO| E
        F -->|11. Proses & Update State DB Lokal| G[(Database Konsumen)]
        F -->|12. Kirim ACK| E
    end

    style B stroke:#333,stroke-width:2px
    style G stroke:#333,stroke-width:2px
    style E stroke:#0288d1,stroke-width:2px
    style D stroke:#0288d1,stroke-width:2px

Implementasi Transactional Outbox Pattern dalam Kode Go #

Berikut adalah contoh implementasi lengkap dalam bahasa Go. Kode ini mendemonstrasikan bagaimana kita menyimpan data pesanan (order) dan pesan outbox ke dalam database PostgreSQL menggunakan satu transaksi SQL yang aman, dan bagaimana proses latar belakang (relay) mengirimkan pesan outbox tersebut ke RabbitMQ secara andal.

package main

import (
	"context"
	"database/sql"
	"encoding/json"
	"fmt"
	"log"
	"time"

	_ "github.com/lib/pq"
	amqp "github.com/rabbitmq/amqp091-go"
)

// Order merepresentasikan data entitas bisnis utama kita.
type Order struct {
	ID        string    `json:"id"`
	UserID    string    `json:"user_id"`
	Amount    float64   `json:"amount"`
	CreatedAt time.Time `json:"created_at"`
}

// OutboxEvent merepresentasikan skema tabel outbox untuk pengiriman event asinkron.
type OutboxEvent struct {
	ID         int64
	EventType  string
	Payload    []byte
	CreatedAt  time.Time
	IsSent     bool
}

// OrderService mengelola operasi bisnis pesanan.
type OrderService struct {
	db *sql.DB
}

// CreateOrder menciptakan pesanan baru menggunakan transaksi database ACID.
func (s *OrderService) CreateOrder(ctx context.Context, order Order) error {
	// 1. Mulai transaksi database
	tx, err := s.db.BeginTx(ctx, nil)
	if err != nil {
		return fmt.Errorf("gagal memulai transaksi: %w", err)
	}
	// Pastikan rollback dilakukan jika terjadi kegagalan sebelum commit
	defer tx.Rollback()

	// 2. Tulis ke tabel utama (orders)
	queryOrder := `INSERT INTO orders (id, user_id, amount, created_at) VALUES ($1, $2, $3, $4)`
	_, err = tx.ExecContext(ctx, queryOrder, order.ID, order.UserID, order.Amount, order.CreatedAt)
	if err != nil {
		return fmt.Errorf("gagal menulis data order: %w", err)
	}

	// Serialisasi data order menjadi payload JSON untuk outbox
	payload, err := json.Marshal(order)
	if err != nil {
		return fmt.Errorf("gagal serialisasi order payload: %w", err)
	}

	// 3. Tulis ke tabel outbox di dalam transaksi yang sama
	queryOutbox := `INSERT INTO outbox (event_type, payload, created_at, is_sent) VALUES ($1, $2, $3, false)`
	_, err = tx.ExecContext(ctx, queryOutbox, "order.created", payload, time.Now())
	if err != nil {
		return fmt.Errorf("gagal menulis data outbox: %w", err)
	}

	// 4. Commit transaksi database secara atomik
	if err := tx.Commit(); err != nil {
		return fmt.Errorf("gagal commit transaksi: %w", err)
	}

	log.Printf("[OrderService] Sukses menyimpan Order ID %s dan Outbox event ke DB", order.ID)
	return nil
}

// OutboxPublisher bertugas membaca tabel outbox dan merelay pesan ke RabbitMQ.
type OutboxPublisher struct {
	db         *sql.DB
	rabbitConn *amqp.Connection
	ch         *amqp.Channel
}

// Run memulai proses polling berkala untuk mengirimkan pesan outbox.
func (p *OutboxPublisher) Run(ctx context.Context, interval time.Duration) {
	ticker := time.NewTicker(interval)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C:
			if err := p.publishPendingEvents(ctx); err != nil {
				log.Printf("[OutboxPublisher] Error saat memproses event tunda: %v", err)
			}
		}
	}
}

func (p *OutboxPublisher) publishPendingEvents(ctx context.Context) error {
	// Ambil daftar event yang belum terkirim dari database
	querySelect := `SELECT id, event_type, payload FROM outbox WHERE is_sent = false ORDER BY id ASC LIMIT 10`
	rows, err := p.db.QueryContext(ctx, querySelect)
	if err != nil {
		return fmt.Errorf("gagal query pending outbox: %w", err)
	}
	defer rows.Close()

	var events []OutboxEvent
	for rows.Next() {
		var ev OutboxEvent
		if err := rows.Scan(&ev.ID, &ev.EventType, &ev.Payload); err != nil {
			return fmt.Errorf("gagal scan outbox row: %w", err)
		}
		events = append(events, ev)
	}

	if len(events) == 0 {
		return nil // Tidak ada pesan yang tertunda
	}

	// Kirim setiap event ke RabbitMQ
	for _, ev := range events {
		// Publikasikan pesan dengan Publisher Confirms aktif
		err = p.ch.PublishWithContext(ctx,
			"order.events", // exchange name
			ev.EventType,    // routing key
			true,            // mandatory
			false,           // immediate
			amqp.Publishing{
				ContentType:  "application/json",
				DeliveryMode: amqp.Persistent, // Pastikan pesan ditulis ke disk di broker
				Body:         ev.Payload,
				Timestamp:    time.Now(),
			},
		)
		if err != nil {
			log.Printf("[OutboxPublisher] Gagal mengirim Event ID %d ke RabbitMQ: %v", ev.ID, err)
			continue // Lanjutkan dengan event berikutnya, coba lagi nanti untuk yang gagal
		}

		// Setelah sukses mengirim ke RabbitMQ, tandai event di database sebagai terkirim
		queryUpdate := `UPDATE outbox SET is_sent = true WHERE id = $1`
		_, err = p.db.ExecContext(ctx, queryUpdate, ev.ID)
		if err != nil {
			log.Printf("[OutboxPublisher] Peringatan: Event ID %d terkirim ke RabbitMQ tapi gagal update status DB: %v", ev.ID, err)
			// Catatan: Ini berpotensi menyebabkan duplikasi pengiriman pesan (at-least-once).
			// Consumer kita harus bersifat idempotent untuk mengatasinya.
		} else {
			log.Printf("[OutboxPublisher] Event ID %d sukses direlay ke RabbitMQ dan diperbarui di DB", ev.ID)
		}
	}

	return nil
}

func main() {
	// Contoh inisialisasi koneksi (ilustratif)
	db, err := sql.Open("postgres", "postgres://user:password@localhost:5432/dbname?sslmode=disable")
	if err != nil {
		log.Fatalf("Gagal koneksi ke PostgreSQL: %v", err)
	}
	defer db.Close()

	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	if err != nil {
		log.Fatalf("Gagal koneksi ke RabbitMQ: %v", err)
	}
	defer conn.Close()

	ch, err := conn.Channel()
	if err != nil {
		log.Fatalf("Gagal membuka channel RabbitMQ: %v", err)
	}
	defer ch.Close()

	// Aktifkan mode Publisher Confirms agar relay mendapat kepastian write dari broker
	if err := ch.Confirm(false); err != nil {
		log.Fatalf("Gagal mengaktifkan Publisher Confirms: %v", err)
	}

	service := &OrderService{db: db}
	publisher := &OutboxPublisher{
		db:         db,
		rabbitConn: conn,
		ch:         ch,
	}

	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	// Jalankan relay publisher di background goroutine
	go publisher.Run(ctx, 2*time.Second)

	// Simulasi pembuatan order baru oleh aplikasi
	newOrder := Order{
		ID:        "order-99120",
		UserID:    "user-887",
		Amount:    150000.0,
		CreatedAt: time.Now(),
	}

	if err := service.CreateOrder(ctx, newOrder); err != nil {
		log.Printf("Gagal membuat order: %v", err)
	}

	// Blok thread utama agar goroutine background tetap berjalan
	time.Sleep(5 * time.Second)
}

Perbandingan Komprehensif: RabbitMQ vs Database #

Tabel di bawah ini merinci perbedaan kemampuan operasional dan batas toleransi kegagalan antara sistem antrean pesan RabbitMQ dan database transaksional (seperti PostgreSQL atau MySQL).

Checklist Review: Apakah Kita Menggunakan RabbitMQ sebagai Database? #

Ketika melakukan audit arsitektur sistem, kita wajib memeriksa apakah ada indikasi penyalahgunaan RabbitMQ sebagai database. Evaluasilah sistem kita menggunakan checklist di bawah ini:

INDIKATOR PENYALAHGUNAAN BROKER:
  □ Apakah ada antrean (queue) yang sengaja dibiarkan menampung pesan tanpa ada konsumen aktif untuk jangka waktu mingguan/bulanan?
  □ Apakah kita sengaja mematikan mekanisme konfirmasi ACK (auto-ack = false) tanpa pernah memanggil basic.ack agar pesan tetap "aman" di dalam queue?
  □ Apakah aplikasi kita mencoba membaca pesan dari tengah antrean dengan teknik menarik seluruh data (pulling) lalu menyaringnya secara manual di memori RAM aplikasi?
  □ Apakah ukuran total data pesan yang belum di-ACK di RabbitMQ melebihi kapasitas memori RAM server broker kita?
  □ Apakah satu-satunya riwayat audit log transaksi bisnis kita hanya disimpan di dalam antrean RabbitMQ tanpa ada salinan permanen di database SQL/NoSQL atau cold storage?

SOLUSI JIKA JAWABAN YA:
  □ Terapkan Transactional Outbox Pattern untuk memisahkan penulisan database dan publikasi event.
  □ Buat consumer worker yang segera memproses pesan, menyimpannya ke database relasional/NoSQL, lalu mengirimkan ACK ke broker dalam hitungan milidetik.
  □ Gunakan antrean RabbitMQ murni sebagai pipa transport transient dengan target ukuran antrean ideal sedekat mungkin ke angka nol.

Ringkasan #

• Destructive Read — Filosofi inti RabbitMQ adalah mengalirkan pesan sementara (transient data). Pesan akan langsung dihapus begitu sukses dikonsumsi dan di-ACK. RabbitMQ tidak dirancang untuk mempertahankan data jangka panjang.
• Bahaya Paging Disk — Menumpuk jutaan pesan di dalam antrean akan menghabiskan RAM broker, memicu batas High Memory Watermark, mengaktifkan kueri paging disk yang sangat lambat, dan membekukan koneksi produsen (flow control).
• Ketiadaan Fitur Kueri — RabbitMQ tidak memiliki query engine, kueri SQL, pembuatan indeks dinamis, kueri pencarian acak, ataupun mekanisme backup dan Point-in-Time Recovery (PITR) seperti database sejati.
• Recovery Booting Lambat — Jumlah backlog pesan persisten yang terlalu besar akan memperlambat proses startup broker pasca-crash karena RabbitMQ harus menyusun ulang indeks antrean dari disk ke memori RAM.
• Transactional Outbox Pattern — Solusi arsitektur yang benar untuk menjamin pengiriman event tanpa membebani broker adalah dengan menulis data utama dan data outbox ke database dalam satu transaksi ACID, lalu menggunakan relay worker independen untuk menerbitkannya ke RabbitMQ.
• Separation of Concerns — Pisahkan media pengaliran pesan sementara (RabbitMQ) dengan media penyimpanan state permanen (PostgreSQL, MySQL, MongoDB, atau Object Storage).

Penutup #

RabbitMQ memberikan kemudahan luar biasa dalam menghubungkan berbagai layanan terdistribusi secara asinkron. Namun, kemudahan ini menuntut disiplin desain yang ketat dari para arsitek sistem. Menggunakan RabbitMQ sebagai database utama adalah jalan pintas yang menukar kemudahan jangka pendek di awal dengan kerapuhan sistem, risiko kehilangan data, dan bencana degradasi performa di masa depan.

Ingatlah prinsip dasar ini: Pesan di dalam RabbitMQ seharusnya membawa instruksi atau notifikasi perubahan status — bukan menjadi tempat penyimpanan status itu sendiri.

Dengan mematuhi batas tanggung jawab antara message broker (transport) dan database (storage) melalui pola desain seperti Transactional Outbox, kita dapat membangun sistem terdistribusi yang tidak hanya memiliki performa tinggi, melainkan juga stabil, tangguh, dan mudah dirawat dalam jangka panjang.

← Sebelumnya: Throughput & Scalability   Berikutnya: Over-Queue →