Kafka vs RabbitMQ: Perbedaan dan Kapan Pakai yang Mana

 Kafka dan RabbitMQ sama-sama message broker, tapi lahir dari dua filosofi yang berbeda. Memilih salah satunya bukan soal mana yang "lebih cepat" — keduanya sudah lebih dari cukup untuk hampir semua aplikasi. Yang menentukan adalah pola kerja dan siapa yang akan mengoperasikannya.

1. Ringkasan Satu Paragraf

Kafka adalah distributed commit log — pesan ditulis ke log yang bisa diputar ulang (replay), disimpan sesuai kebijakan retensi (default 7 hari), dan tidak dihapus setelah dibaca. Consumer menggeser pointer (offset), bukan "mengambil lalu menghapus".

RabbitMQ adalah message broker klasik berbasis AMQP — pesan dirutekan lewat exchange ke queue, lalu dihapus setelah di-acknowledge. Fokusnya pada routing fleksibel dan jaminan per-pesan.

"RabbitMQ built its reputation as the default choice for messaging and task queueing; Kafka built its reputation as the default choice for event streaming."
— Dokumentasi resmi RabbitMQ

Kabar penting 2025–2026: garis pemisah ini sudah kabur di kedua sisi. RabbitMQ punya streams (log ter-replikasi) sejak versi 3.9 (2021), dan Kafka mulai menambahkan queue semantics (KIP-932) di versi 4.0. Jadi pertanyaan "mana yang lebih baik" sekarang bukan soal kemampuan, tapi soal beban kerja dan operasional.

2. Arsitektur Kafka

Model mentalnya: topik → partisi → offset.

Producer → Topic "orders" (3 partisi) ├── Partition 0: [0][1][2][3]... ← append-only log ├── Partition 1: [0][1][2]... └── Partition 2: [0][1][2][3][4]... ↓ Consumer Group "billing" (tiap partisi → tepat 1 consumer) Consumer Group "analytics" (grup lain baca SEMUA data sendiri)

• Topic — aliran event bernama, mirip tabel di database.
• Partition — unit paralelisme dan urutan. Urutan dijamin di dalam partisi, tidak antar partisi.
• Offset — posisi record dalam partisi (0, 1, 2, …). Commit offset berarti "sudah sampai sini".
• Consumer Group — sekumpulan consumer berbagi partisi. Satu partisi dibaca tepat satu consumer per grup, sehingga jumlah partisi = plafon paralelisme.
• Replication Factor — tiap partisi punya 1 leader + N−1 follower. acks=all + min.insync.replicas=2 adalah kontrak durabilitasnya.
• KRaft — sejak Kafka 3.3 dan wajib di 4.0, menggantikan ZooKeeper. Failover controller turun dari detik-menit menjadi milidetik, dan kapasitas cluster naik dari puluhan ribu ke jutaan partisi.

Aturan paling penting untuk desain: key menentukan partisi — partition = hash(key) % num_partitions. Pakai order_id sebagai key maka semua event pesanan itu masuk ke partisi yang sama dan terproses berurutan. Tanpa key, record disebar dan urutan hilang.

Ingat juga: jumlah partisi tidak bisa dikurangi, dan menambah partisi mengubah pemetaan key. Pilih jumlah partisi dengan headroom sejak awal.

3. Arsitektur RabbitMQ

Model mentalnya: exchange → binding → queue.

Producer → Exchange (direct/topic/fanout/headers) ├── binding "order.*" → Queue A → Consumer ├── binding "order.paid" → Queue B → Consumer └── binding "#" → Queue C → Consumer

Jenis Exchange	Cara Routing
Direct	Routing key harus sama persis dengan binding key
Fanout	Broadcast ke semua queue yang terikat
Topic	Pola wildcard: order.* (satu kata), order.# (nol atau lebih kata)
Headers	Berdasarkan atribut header, bukan routing key

Konsep kunci lain:

• Queue — buffer pesan. Pesan dihapus setelah di-ack.
• Binding — "link" antara exchange dan queue.
• Prefetch / QoS — berapa pesan boleh dipegang satu consumer sekaligus.
• Quorum Queue — queue ter-replikasi (Raft) untuk durabilitas tinggi; satu quorum queue menangani sekitar 80.000 pesan/detik sambil fsync setiap pesan.
• Streams — fitur log ala Kafka; satu stream bisa membaca beberapa juta pesan/detik saat chunk terisi penuh.

Fitur yang Kafka tidak punya secara native: request/reply (RPC), priority queue, TTL per pesan, delayed message, dead-letter exchange, serta protokol legacy seperti MQTT dan STOMP.

4. Perbandingan Langsung

Aspek	Apache Kafka	RabbitMQ
Model	Distributed commit log	Message broker (AMQP)
Setelah dibaca	Tetap ada (retensi waktu/ukuran)	Dihapus setelah ack
Replay history	Bisa rewind offset	Hanya via Streams
Urutan	Per partisi, dijamin ketat	Per queue, melemah dengan banyak consumer
Fan-out	Native — grup berbeda baca semua	Perlu exchange/fanout
Routing kompleks	Terbatas	Sangat fleksibel (topic/header exchange)
RPC / request-reply	Perlu pola manual	Built-in
Throughput puncak	Sangat tinggi (juta pesan/detik)	Tinggi (ratusan ribu/detik)
Latensi	Baik pada beban tinggi	Lebih rendah pada beban rendah
Delivery guarantee	Exactly-once native (transaksi)	At-least-once + dedup di aplikasi
Unit skalabilitas	Partisi	Queue / prefetch
Metadata	KRaft (internal, sejak 4.0)	Erlang cluster
Operator K8s	Strimzi (CNCF, terpisah)	Operator resmi dari tim RabbitMQ

Catatan soal benchmark — jangan tertipu angka

Benchmark Confluent (vendor Kafka) mencatat Kafka 15× throughput RabbitMQ (605 MB/s vs 38 MB/s). Tapi dokumentasi RabbitMQ membalas dengan adil:

"RabbitMQ is slow is the most common misconception. A benchmark that tunes one side hard while leaving the other on defaults is comparing tuning effort, not what the systems are capable of."

Studi akademik pun tidak sepakat satu suara:

• JUTI ITS — RabbitMQ unggul pada pesan individual bervolume tinggi dengan latensi rendah; Kafka unggul pada beban ekstrem berkelanjutan. Pada pesan 100 KB: RabbitMQ 117 msg/s vs Kafka 12 msg/s.
• MDPI Telecom — Kafka menang jelas soal throughput di semua ukuran pesan; RabbitMQ kedua dengan jarak signifikan.
• Kesimpulan realistis — keduanya sanggup melebihi kebutuhan 99% aplikasi. Yang menentukan adalah pola kerja, bukan papan skor benchmark.

5. Kapan Pakai Kafka

Pilih Kafka kalau:

1. Event streaming / pipeline data real-time — ribuan sampai jutaan event per detik.
2. Butuh replay — konsumen baru perlu membaca ulang data lama (misal service baru di-deploy dan harus memproses 7 hari ke belakang).
3. Fan-out ke banyak sistem — satu event dikonsumsi analytics, fraud-detection, notification, dan data warehouse secara independen.
4. Log aggregation — mengumpulkan log dari ratusan service.
5. Event sourcing / CDC — menjadikan log sebagai sumber kebenaran (Kafka Connect + Debezium).
6. Analitik streaming — Kafka Streams, Flink, Spark Structured Streaming.
7. Exactly-once antar sistem Kafka — pola consume-process-produce dengan transaksi.

Contoh nyata: LinkedIn (asal Kafka), Netflix, Uber, dan Twitter.

6. Kapan Pakai RabbitMQ

Pilih RabbitMQ kalau:

1. Task / work queue — kirim email, generate PDF, resize gambar. Kirim ke satu worker, hapus setelah selesai.
2. Routing kompleks per pesan — "event ini harus ke 3 dari 10 consumer, berdasarkan atribut" → topic/header exchange.
3. Request/reply (RPC) antar microservice.
4. Prioritas pesan — pesan VIP diproses lebih dulu.
5. Delayed / scheduled message, TTL per pesan, dead-letter handling — semua built-in.
6. Volume moderat dengan latensi rendah per pesan.
7. Integrasi protokol legacy — MQTT untuk IoT, STOMP untuk web.

Contoh nyata: banyak sistem e-commerce dan fintech untuk orkestrasi job.

7. Pola Keputusan Cepat

Konsumen baru perlu baca ulang data lama? YA → Kafka Routing per-pesan rumit (wildcard/header)? YA → RabbitMQ Volume > 100.000 pesan/detik berkelanjutan? YA → Kafka Butuh RPC / priority / delayed / TTL? YA → RabbitMQ Volume moderat + task queue sederhana? → RabbitMQ

Aturan satu baris: Kafka untuk aliran data dan riwayat; RabbitMQ untuk tugas dan routing.

8. Bisa Dipakai Bersama

Ini pola yang umum di produksi dan sering dilupakan:

Sensor/App → [Kafka] streaming, replay, fan-out ke banyak sistem ↓ Kafka consumer [RabbitMQ] task queue, routing per-pesan, retry, DLQ ↓ Worker pool

Kafka menyimpan riwayat dan skala; RabbitMQ menangani distribusi tugas yang butuh retry, prioritas, dan dead-letter. Jembatan antar keduanya: Apache Camel, Spring Integration, atau bridge custom (Kafka consumer → RabbitMQ publisher).

9. Operasional: Jangan Abaikan Ini

Kafka

• Partisi tidak bisa dikurangi — over-partition sedikit di awal.
• Consumer harus memanggil poll() dalam max.poll.interval.ms, atau dikeluarkan dari grup dan pekerjaannya diulang di tempat lain. Ini penyebab lag paling sering.
• Pakai assignor cooperative-sticky (atau protokol grup baru Kafka 4.0) agar rebalance tidak menghentikan seluruh grup.
• Monitor consumer lag — metrik kesehatan nomor satu.

RabbitMQ

• Prefetch yang salah (terlalu besar) membuat satu consumer menelan semua pesan.
• Queue yang menumpuk tanpa consumer akan menahan memori — set x-max-length atau TTL.
• Selalu definisikan dead-letter exchange sejak awal.
• Quorum queue untuk durabilitas; classic queue untuk kecepatan.

10. Kesimpulan

Kalau kamu…	Pilih
Bangun platform data / event streaming	Kafka
Butuh replay dan audit trail penuh	Kafka
Bangun sistem job queue / microservice	RabbitMQ
Butuh routing rumit dan RPC	RabbitMQ
Skala ratusan ribu–juta pesan per detik	Kafka
Tim kecil, mau yang paling simpel dijalankan	RabbitMQ
Butuh keduanya	Pakai bersama

Yang penting diingat: keduanya sudah saling meniru kemampuan satu sama lain. Keputusan yang benar bukan "mana yang lebih cepat", tapi "pola kerja saya seperti apa, dan siapa yang akan mengoperasikannya".