Ordering Comparison #

Dalam sistem messaging, ordering sering dianggap otomatis terjadi.

Padahal dalam sistem terdistribusi, menjaga urutan pesan adalah salah satu tantangan paling sulit.

RabbitMQ dan Kafka sama-sama menyediakan ordering.

Namun cara keduanya menjaga urutan sangat berbeda — dan perbedaannya berdampak langsung pada desain arsitektur.

Artikel ini membahas perbandingan ordering antara RabbitMQ dan Kafka secara mendalam.

“Ordering bukan sekadar urutan datang — tetapi jaminan bahwa sistem memproses realitas dalam kronologi yang benar.”

Ordering di RabbitMQ #

FIFO per Queue #

Secara default, RabbitMQ menjamin:

  • FIFO (First-In-First-Out) per queue

Artinya:

  • Message yang dipublish lebih dulu
  • Akan masuk queue lebih dulu
  • Akan didelivery lebih dulu

Namun jaminan ini berlaku dalam kondisi tertentu.


Faktor yang Bisa Mengubah Ordering di RabbitMQ #

Walaupun FIFO adalah default, beberapa kondisi dapat memengaruhi urutan:

Multiple Consumer (Competing Consumer) #

Jika satu queue memiliki banyak consumer:

  • Message dibagi ke beberapa consumer
  • Waktu proses berbeda-beda

Akibatnya:

  • Urutan penyelesaian bisa berbeda dari urutan publish

FIFO dijaga di level delivery, bukan di level completion.


Requeue #

Jika message di-nack dan di-requeue:

  • Message bisa kembali ke posisi tertentu dalam queue
  • Ordering bisa berubah

Priority Queue #

Jika queue menggunakan priority:

  • Message dengan priority lebih tinggi bisa didahulukan
  • FIFO tidak lagi murni

Retry Pattern dengan DLX #

Message yang gagal dan masuk retry queue lalu kembali:

  • Akan diproses setelah delay
  • Bisa melompati message lain

RabbitMQ menjaga FIFO, tetapi tidak menjamin strict ordering dalam semua skenario kompleks.


Ordering di Kafka #

Kafka memiliki model yang berbeda.

Ordering per Partition #

Kafka menjamin:

  • Ordering dalam satu partition

Artinya:

  • Message dalam partition A diproses sesuai urutan offset
  • Tidak ada reordering di dalam partition tersebut

Namun:

  • Tidak ada global ordering antar partition

Bagaimana Kafka Menjaga Ordering? #

Kafka menggunakan:

  • Append-only log
  • Offset incremental

Setiap message memiliki offset unik dalam partition.

Consumer membaca berdasarkan offset secara berurutan.

Karena log immutable dan sequential write:

  • Ordering dalam partition sangat kuat dan stabil

Perbandingan Ordering #

AspekRabbitMQKafka
Model dasarFIFO queueAppend-only log
Scope orderingPer queuePer partition
Global orderingTidak adaTidak ada
Bisa berubah karena retryYaTidak (di partition)
Multi consumer impactBisa ubah completion orderPartition dibagi antar consumer

RabbitMQ: FIFO delivery. Kafka: FIFO per partition offset.


Strict Ordering: Mana Lebih Kuat? #

Jika hanya satu queue dan satu consumer:

  • RabbitMQ memberi strict FIFO

Jika banyak consumer dan retry kompleks:

  • Ordering bisa terpengaruh

Jika Kafka menggunakan satu partition:

  • Ordering sangat kuat
  • Tetapi throughput terbatas

Untuk throughput tinggi dengan banyak partition:

  • Ordering hanya dijaga per key (jika key mapping konsisten)

Kafka memungkinkan ordering per entity (misal per user ID) dengan partitioning key.


Tradeoff Ordering dan Scalability #

Strict ordering sering kali bertentangan dengan scalability.

RabbitMQ:

  • Single queue + single consumer → ordering kuat, throughput terbatas
  • Banyak consumer → throughput naik, ordering completion melemah

Kafka:

  • Single partition → ordering kuat, throughput terbatas
  • Banyak partition → throughput tinggi, global ordering hilang

Keduanya memiliki tradeoff serupa dengan pendekatan berbeda.


Use Case yang Membutuhkan Ordering Ketat #

Contoh:

  • Financial transaction per account
  • Inventory update per product
  • State machine per entity

Strategi umum:

RabbitMQ:

  • Gunakan satu queue per entity
  • Atau partition manual berdasarkan key

Kafka:

  • Gunakan partition key berdasarkan entity ID
  • Pastikan semua event entity masuk partition yang sama

Ordering harus dirancang, bukan diasumsikan.


Misconception yang Sering Terjadi #

“Kafka selalu lebih kuat dalam ordering.”

Tidak selalu.

Kafka kuat dalam ordering per partition. RabbitMQ kuat dalam FIFO per queue.

Masalahnya bukan siapa lebih kuat. Masalahnya adalah ruang lingkup jaminannya.


Ringkasan #

RabbitMQ:

  • FIFO per queue
  • Bisa berubah karena requeue atau multi-consumer
  • Cocok untuk workflow terkontrol

Kafka:

  • FIFO per partition
  • Sangat stabil dalam satu partition
  • Cocok untuk event stream per entity

Penutup #

Ordering dalam sistem terdistribusi bukan jaminan global.

Ia selalu memiliki batasan ruang lingkup.

RabbitMQ menjaga urutan dalam queue. Kafka menjaga urutan dalam partition.

Memahami batasan ini sangat penting agar sistem tidak dibangun dengan asumsi yang salah.

Karena dalam sistem yang kompleks, kesalahan dalam memahami ordering sering kali baru terlihat ketika sudah terlambat.

Dan ketika itu terjadi, memperbaikinya jauh lebih mahal daripada merancangnya dengan benar sejak awal.

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact