Over Queue #

Dalam desain berbasis RabbitMQ, membuat queue itu mudah.

Sangat mudah.

Karena itu, salah satu anti-pattern yang sering muncul adalah Overqueue — kondisi di mana sistem memiliki terlalu banyak queue tanpa kebutuhan arsitektural yang jelas.

Alih-alih membuat sistem lebih modular, overqueue justru dapat:

• Meningkatkan kompleksitas operasional
• Menyulitkan observability
• Menyebabkan fragmentasi traffic
• Memperbesar risiko salah routing

Artikel ini membahas apa itu overqueue, bagaimana ia terjadi, dan bagaimana menghindarinya.

“Queue membantu memecah sistem menjadi lebih terstruktur — tetapi terlalu banyak queue bisa memecah sistem menjadi tidak terkendali.”

Apa Itu Overqueue? #

Overqueue adalah kondisi ketika:

• Setiap variasi kecil use case dibuatkan queue terpisah
• Setiap consumer dibuatkan queue sendiri tanpa kebutuhan
• Queue dibuat berdasarkan asumsi masa depan yang belum tentu terjadi

Contoh:

Alih-alih satu queue order.events, sistem membuat:

• order.created
• order.updated
• order.deleted
• order.payment.started
• order.payment.failed
• order.payment.success

Padahal semua bisa dirutekan melalui topic exchange dengan satu atau dua queue terstruktur.

Mengapa Overqueue Terjadi? #

Beberapa penyebab umum:

1️⃣ Salah Paham tentang Isolasi #

Berpikir bahwa semakin banyak queue, semakin aman sistem.

Padahal isolasi bisa dilakukan dengan routing key dan consumer logic.

2️⃣ Menghindari Desain Routing yang Baik #

Daripada mendesain topic pattern dengan benar, lebih mudah membuat queue baru.

3️⃣ Fear-Based Architecture #

“Nanti kalau butuh, sudah ada queue-nya.”

Desain berdasarkan ketakutan, bukan kebutuhan nyata.

4️⃣ Kurangnya Dokumentasi Kontrak Event #

Tanpa kontrak yang jelas, setiap tim membuat queue sendiri.

Dampak Overqueue #

1️⃣ Kompleksitas Operasional #

• Puluhan hingga ratusan queue
• Sulit dipantau
• Sulit dituning
• Hard to debug

2️⃣ Fragmentasi Traffic #

Traffic tersebar tipis di banyak queue.

Akibatnya:

• Consumer idle di sebagian queue
• Consumer overload di queue lain

Throughput tidak optimal.

3️⃣ Konfigurasi Tidak Konsisten #

Sebagian queue:

• Durable
• Sebagian tidak
• Sebagian pakai DLX
• Sebagian tidak

Arsitektur menjadi inkonsisten.

4️⃣ Monitoring Menjadi Sulit #

Metric seperti:

• Queue depth
• Unacked count
• Retry rate

Menjadi tersebar dan sulit dipahami secara sistemik.

Overqueue vs Legitimate Partitioning #

Tidak semua banyak queue adalah anti-pattern.

Kasus yang valid:

• Partitioning berdasarkan domain besar
• Isolasi workload heavy vs light
• SLA berbeda
• Multi-tenant isolation

Perbedaannya ada pada:

Tujuan arsitektural yang jelas.

Overqueue terjadi ketika queue dibuat tanpa prinsip desain yang konsisten.

Prinsip Desain yang Lebih Sehat #

1️⃣ Gunakan Routing Key Secara Maksimal #

Topic exchange memungkinkan satu queue menangani banyak event dengan pattern matching.

2️⃣ Pisahkan Berdasarkan SLA, Bukan Berdasarkan Nama Event #

Jika dua jenis event memiliki:

• SLA berbeda
• Retry policy berbeda
• Throughput berbeda

Maka queue terpisah masuk akal.

Jika tidak, tidak perlu dipisah.

3️⃣ Desain Berdasarkan Domain, Bukan Event Individu #

Contoh lebih sehat:

• order.events
• payment.events
• notification.tasks

Bukan per aksi kecil.

4️⃣ Dokumentasikan Kontrak Event #

Dengan kontrak yang jelas:

• Tim tidak membuat queue sembarangan
• Routing menjadi konsisten

Indikator Sistem Mengalami Overqueue #

• Jumlah queue terus bertambah tanpa review arsitektur
• Tidak ada dokumentasi peran masing-masing queue
• Banyak queue dengan traffic sangat rendah
• Banyak queue tanpa consumer aktif
• Monitoring dashboard sulit dibaca

Jika ini terjadi, kemungkinan besar desain sudah melebar tanpa kontrol.

Best Practice untuk Menghindari Overqueue #

• Review desain queue secara berkala
• Gunakan naming convention berbasis domain
• Hindari membuat queue hanya karena “lebih rapi”
• Kelompokkan event yang serupa
• Gunakan topic exchange sebelum membuat queue baru

Queue adalah boundary arsitektural.

Ia tidak boleh dibuat tanpa alasan kuat.

Ringkasan #

Overqueue adalah anti-pattern ketika:

• Queue dibuat terlalu granular
• Tanpa alasan SLA atau isolation
• Tanpa desain routing matang

Dampaknya:

• Kompleksitas
• Fragmentasi
• Monitoring sulit

Solusinya:

• Desain berbasis domain
• Gunakan routing dengan bijak
• Evaluasi kebutuhan nyata sebelum menambah queue

Penutup #

Queue memang alat yang sangat kuat dalam arsitektur RabbitMQ.

Namun seperti semua alat yang kuat, ia harus digunakan dengan disiplin.

Terlalu sedikit queue bisa membuat sistem tidak fleksibel. Terlalu banyak queue bisa membuat sistem tidak terkendali.

Arsitektur yang matang bukan tentang berapa banyak queue yang dimiliki.

Tetapi tentang apakah setiap queue memiliki alasan eksistensi yang jelas dan terukur.

Karena dalam sistem terdistribusi, kompleksitas yang tidak perlu adalah musuh yang paling mahal.