Queueing #

Dalam message lifecycle RabbitMQ, setelah tahap:

• Publishing
• Routing & Binding
• (Keputusan tentang Persistence)

Message memasuki fase yang sering diremehkan tetapi sangat krusial: Queueing.

Queueing adalah fase ketika message:

• Masuk ke dalam queue (enqueue)
• Berada dalam status ready
• Disimpan di memory atau disk
• Menunggu untuk dikirim ke consumer

Di sinilah tekanan sistem terakumulasi. Di sinilah backlog terbentuk. Di sinilah performa dan ketahanan diuji.

Artikel ini membahas fase Queueing sebagai bagian eksplisit dalam message lifecycle RabbitMQ.

“Pesan tidak langsung diproses setelah dirutekan — ia menunggu. Dan dalam penantian itu, seluruh stabilitas sistem diuji.”

Posisi Queueing dalam Lifecycle #

1. Diagram Lengkap Lifecycle dengan Queueing #

Producer
   |
   v
Exchange
   |
   v
Routing & Binding
   |
   v
Queueing (Enqueue & Storage)
   |
   v
Delivery
   |
   v
Ack / Nack

Queueing adalah jembatan antara routing dan delivery.

Apa yang Terjadi Saat Enqueue? #

Setelah routing memutuskan queue tujuan:

1. Broker membuat entry message di queue
2. Message masuk ke status “ready”
3. Jika persistent → dijadwalkan untuk ditulis ke disk
4. Jika quorum → dicatat dalam Raft log

Message sekarang berada dalam antrian.

Belum diproses. Belum dihapus. Belum selesai.

Ready vs Unacked State #

Dalam queue terdapat dua status utama:

• Ready → belum dikirim ke consumer
• Unacked → sudah dikirim tetapi belum di-ack

Queueing hanya mencakup status ready.

Delivery memindahkan message ke unacked.

Penyimpanan: Memory vs Disk #

Bagaimana message disimpan tergantung tipe queue.

Classic Queue (Default) #

• Memory-first
• Ditulis ke disk jika persistent
• Bisa spill jika memory pressure

Lazy Queue #

• Disk-first
• Mengurangi penggunaan memory

Quorum Queue #

• Ditulis ke Raft log
• Direplikasi ke follower
• Commit setelah mayoritas setuju

Queueing adalah fase di mana keputusan storage terjadi.

Ordering dalam Queueing #

Queue menjaga FIFO ordering per queue.

Namun ordering bisa berubah jika:

• Message di-requeue
• Menggunakan priority queue
• Multiple consumer dengan nack

Secara default, enqueue mempertahankan urutan publish.

TTL Dimulai di Fase Ini #

Jika queue atau message memiliki TTL:

• Timer dihitung saat message berada di queue
• Jika expired sebelum delivery → message dibuang atau masuk DLX

Artinya Queueing juga adalah fase countdown waktu hidup message.

Max-Length dan Overflow #

Queue dapat memiliki batas panjang.

Jika:

• Queue penuh

Maka kebijakan overflow bisa terjadi:

• Drop oldest
• Reject publish
• Dead-letter

Semua ini terjadi saat fase Queueing.

Backlog dan Pressure Point #

Jika consumer lambat:

• Ready message meningkat
• Memory usage naik
• Disk I/O meningkat

Jika memory watermark terlampaui:

• Flow control aktif
• Producer diblokir

Queueing adalah fase di mana tekanan sistem terlihat jelas.

Queueing dalam Cluster dan Quorum #

Pada quorum queue:

• Enqueue berarti append ke distributed log
• Mayoritas node harus setuju
• Ordering dijaga oleh log index

Queueing bukan hanya penyimpanan lokal.

Ia adalah proses consensus.

Risiko di Fase Queueing #

Backlog Tidak Terkontrol #

Queue terus bertambah karena consumer lambat.

Disk Bottleneck #

Jika persistent atau quorum digunakan.

Memory Pressure #

Jika classic queue tanpa lazy dan backlog besar.

Silent Drop karena Overflow Policy #

Jika max-length tanpa pengawasan.

Best Practice Production #

• Monitor queue depth (ready & unacked)
• Monitor memory watermark
• Monitor disk I/O
• Gunakan lazy queue jika backlog besar
• Gunakan quorum untuk reliability
• Tentukan overflow policy secara eksplisit

Queueing harus terlihat dan terukur.

Ringkasan #

Penutup #

Queueing adalah fase yang tampak pasif — tetapi sebenarnya paling menentukan stabilitas sistem.

Di sinilah:

• Backlog terbentuk
• Memory ditekan
• Disk bekerja keras
• Flow control bisa aktif

Jika publishing adalah awal perjalanan pesan, dan delivery adalah interaksi dengan bisnis, maka queueing adalah ruang tunggu yang menentukan apakah sistem tetap stabil atau runtuh di bawah tekanan.

Dalam arsitektur RabbitMQ yang matang, memahami queueing bukan sekadar memahami antrian — tetapi memahami bagaimana sistem bertahan saat tidak ada yang segera memproses pesan.