Persistent #

Dalam lifecycle RabbitMQ, setelah message dipublish dan dirutekan, ada satu pertanyaan krusial:

Apakah pesan tersebut benar-benar aman dari crash?

Jawabannya bergantung pada persistence.

Persistence bukan hanya soal menulis ke disk. Ia adalah kombinasi dari:

• Delivery mode message
• Tipe queue
• Mekanisme confirm
• Replikasi (jika menggunakan quorum queue)

Artikel ini membahas tahap persistence sebagai bagian penting dalam message lifecycle RabbitMQ.

“Sebuah pesan dianggap ‘terkirim’ ketika dipublish. Ia dianggap ‘aman’ hanya ketika benar-benar disimpan.”

Apa Itu Persistent Message? #

Saat producer melakukan publish, ia dapat menentukan properti:

delivery_mode = 1  → transient
delivery_mode = 2  → persistent

Jika delivery_mode = 2, message ditandai sebagai persistent.

Namun penting dipahami:

Persistent message tidak otomatis berarti aman.

Persistence baru bermakna jika queue juga durable.

Hubungan Persistence dan Durable Queue #

Agar message bertahan restart broker:

• Queue harus durable
• Message harus persistent

Jika salah satu tidak terpenuhi:

• Message bisa hilang saat restart

Diagram Kombinasi Persistence #

Durable Queue + Persistent Message   → Recoverable
Durable Queue + Transient Message    → Message hilang
Transient Queue + Persistent Message → Queue hilang
Transient Queue + Transient Message  → Hilang total

Persistence adalah kombinasi, bukan satu flag tunggal.

Apa yang Terjadi Saat Message Persistent Dipublish? #

Pada classic queue:

1. Message diterima broker
2. Ditulis ke memory
3. Disinkronisasi ke disk (bergantung konfigurasi)
4. Confirm dikirim ke producer (jika confirm aktif)

Pada quorum queue:

1. Message diterima leader
2. Direplikasi ke follower
3. Commit setelah mayoritas setuju
4. Confirm dikirim ke producer

Persistence pada quorum queue juga melibatkan replication log (Raft log).

Publisher Confirm dan Persistence #

Persistent message tanpa publisher confirm tetap berisiko.

Tanpa confirm:

• Producer tidak tahu apakah message sudah benar-benar tersimpan
• Jika broker crash sebelum flush disk, message bisa hilang

Dengan publisher confirm:

• Producer mendapat sinyal bahwa message telah committed

Persistence dan confirm adalah dua mekanisme yang saling melengkapi.

Disk Flush dan Fsync #

RabbitMQ tidak selalu melakukan fsync setiap publish.

Ada optimisasi batching disk write untuk performa.

Artinya dalam crash mendadak:

• Ada kemungkinan kehilangan message yang belum tersinkronisasi

Untuk sistem dengan SLA tinggi, konfigurasi disk dan confirm sangat penting.

Persistence dalam Cluster #

Jika menggunakan quorum queue:

• Persistence tidak hanya berarti disimpan di satu node
• Message direplikasi ke beberapa node
• Commit membutuhkan mayoritas

Ini meningkatkan ketahanan terhadap:

• Node crash
• Hardware failure

Namun meningkatkan latency write.

Performa vs Ketahanan #

Persistent message memiliki konsekuensi:

• Disk I/O meningkat
• Latency publish bertambah
• Throughput bisa menurun

Transient message lebih cepat karena:

• Tidak perlu write disk yang berat

Pemilihan persistence adalah keputusan arsitektural, bukan sekadar default setting.

Crash Scenario Analysis #

Broker Restart Normal #

Jika durable + persistent:

• Message akan dipulihkan saat broker hidup kembali

Crash Mendadak Sebelum Flush #

Tanpa confirm atau dengan konfigurasi disk tertentu:

• Message bisa hilang

Node Failure dalam Quorum #

Jika mayoritas node masih hidup:

• Message tetap aman

Jika mayoritas hilang:

• Queue berhenti menerima write
• Konsistensi tetap dijaga

Kesalahan Umum #

Mengira Persistent = 100% Aman #

Tanpa confirm dan konfigurasi tepat, tetap ada risiko.

Tidak Mengaktifkan Persistence pada Data Kritis #

Message transaksi bisnis harus persistent.

Mengaktifkan Persistence Tanpa Memperhatikan Disk #

Disk lambat bisa menjadi bottleneck besar.

Best Practice Production #

• Gunakan durable queue untuk data penting
• Gunakan persistent message untuk transaksi bisnis
• Aktifkan publisher confirm
• Monitor disk I/O dan latency confirm
• Gunakan quorum queue untuk high availability

Persistence harus dirancang secara menyeluruh, bukan parsial.

Ringkasan #

Penutup #

Persistence adalah tahap dalam lifecycle di mana message berubah dari sekadar data yang dikirim menjadi data yang benar-benar disimpan.

Tanpa persistence yang benar, RabbitMQ hanyalah buffer sementara.

Dengan persistence yang tepat, RabbitMQ menjadi sistem messaging yang mampu bertahan terhadap restart, crash, bahkan kegagalan node.

Namun seperti semua mekanisme ketahanan, ia datang dengan biaya performa.

Dalam arsitektur production yang matang, persistence bukan sekadar opsi — ia adalah keputusan sadar tentang seberapa besar sistem menghargai data yang dikirimnya.