Queue #

Jika exchange adalah router, dan message adalah unit data, maka queue adalah tempat realitas terjadi.

Di dalam queue:

• Pesan menunggu diproses
• Lonjakan traffic diserap
• Ordering diuji
• Backpressure mulai terasa

Memahami queue secara mendalam adalah kunci untuk mendesain sistem RabbitMQ yang stabil di production.

“Queue bukan hanya tempat menaruh pesan — ia adalah titik di mana tekanan sistem terakumulasi dan ketahanan arsitektur diuji.”

Apa Itu Queue? #

Queue adalah struktur penyimpanan di RabbitMQ yang:

• Menyimpan message setelah dirutekan oleh exchange
• Mengirim message ke consumer
• Menjaga status unacknowledged message

Producer tidak pernah mengirim langsung ke queue.

Message selalu melewati exchange terlebih dahulu.

Lifecycle Queue dalam Sistem #

1. Alur Message Menuju Queue #

Producer
   |
   v
Exchange
   |
   v
Queue
   |
   v
Consumer

Queue menjadi buffer antara producer dan consumer.

Tipe-Tipe Queue dalam RabbitMQ #

RabbitMQ memiliki beberapa tipe queue utama.

Classic Queue #

• Tipe tradisional
• Cocok untuk workload umum
• Tidak direplikasi secara default

Jika node tempat queue berada mati, queue tidak tersedia.

Quorum Queue #

• Dirancang untuk reliability tinggi
• Menggunakan Raft consensus
• Data direplikasi ke beberapa node
• Direkomendasikan untuk production modern

Lebih aman, tetapi overhead lebih besar.

Stream Queue (Opsional dalam versi terbaru) #

• Optimized untuk event streaming
• Cocok untuk replay use case
• Behavior berbeda dari queue klasik

Namun ini berbeda paradigma dari queue biasa.

Durable vs Non-Durable Queue #

Durable Queue #

• Definisi queue disimpan ke disk
• Tetap ada setelah broker restart

Non-Durable Queue #

• Hilang setelah broker restart

Penting:

Durable queue tidak otomatis membuat message durable.

Message juga harus persistent.

Exclusive dan Auto-Delete Queue #

Exclusive Queue #

• Hanya bisa digunakan oleh satu connection
• Biasanya untuk RPC atau temporary response queue

Auto-Delete Queue #

• Akan dihapus saat tidak ada consumer

Ini berguna untuk pola komunikasi sementara.

Queue sebagai Buffer dan Pressure Point #

Queue menyerap lonjakan traffic.

Namun jika consumer lambat:

• Queue akan terus bertambah panjang
• Memory dan disk usage meningkat

Queue panjang bukan selalu tanda sehat.

Ia bisa menjadi indikator bottleneck downstream.

Ordering dalam Queue #

Secara default queue bersifat FIFO.

Namun ordering bisa berubah jika:

• Banyak consumer paralel
• Message di-requeue
• Priority queue digunakan

Jika ordering penting:

• Gunakan single consumer
• Atau desain partitioned queue

Prefetch dan Distribusi Message #

Jika satu queue memiliki banyak consumer:

• RabbitMQ mendistribusikan message secara round-robin
• Prefetch mengatur berapa banyak message yang bisa diterima

Queue tidak memproses message.

Ia hanya mendistribusikan.

Panjang Queue dan Monitoring #

Beberapa metrik penting:

• Ready messages
• Unacknowledged messages
• Consumer count
• Message rate (publish/consume)

Queue yang terus bertambah tanpa turun adalah tanda masalah.

Monitoring wajib dilakukan di production.

Dead Letter Queue (DLQ) #

Queue dapat dikonfigurasi memiliki dead-letter exchange.

Jika message:

• Expired
• Ditolak (nack tanpa requeue)
• Melebihi max length

Maka message diarahkan ke DLQ.

Ini membantu isolasi error.

Desain Queue yang Baik #

Beberapa prinsip:

Jangan Gunakan Satu Queue untuk Semua Event #

Ini menciptakan bottleneck.

Gunakan Quorum Queue untuk Data Kritis #

Classic queue cocok untuk workload non-critical.

Hindari Message Terlalu Besar #

Queue bukan object storage.

Pertimbangkan Partitioning #

Untuk throughput tinggi:

• Gunakan beberapa queue
• Bagi berdasarkan key tertentu

Ringkasan #

Penutup #

Queue adalah titik paling krusial dalam RabbitMQ.

Di sinilah:

• Tekanan sistem terlihat
• Ordering diuji
• Reliability diuji
• Backpressure terasa

Memahami queue bukan hanya soal tahu cara declare queue.

Ia soal memahami bagaimana sistem akan berperilaku saat traffic tinggi, saat consumer lambat, atau saat node gagal.

Karena pada akhirnya, kekuatan arsitektur asynchronous selalu diuji di satu tempat: queue.