Apache Kafka Adalah: Cara Kerja, Fungsi & Kebutuhannya

Setiap aplikasi yang Anda bangun pada akhirnya perlu berbicara dengan aplikasi lain. Awalnya sederhana. Sistem pesanan memanggil sistem pembayaran lewat API, satu koneksi langsung, dan semuanya berjalan. Masalah muncul ketika sistem ketiga, keempat, dan kelima ikut membutuhkan informasi pesanan yang sama. Tim gudang ingin tahu, tim analitik ingin tahu, tim notifikasi juga ingin tahu.

Setiap kebutuhan baru berarti satu koneksi baru yang harus ditulis dan dipelihara. Lebih repot lagi, panggilan langsung menuntut kedua belah pihak hidup bersamaan. Saat sistem penerima sedang dimatikan untuk pemeliharaan, data yang dikirim ke arahnya menghilang begitu saja.

Apache Kafka adalah perangkat lunak yang lahir dari persoalan ini. Alih-alih memaksa setiap sistem saling memanggil, Kafka menaruh satu catatan bersama di tengah. Pengirim menulis ke catatan itu, dan siapa pun yang membutuhkan boleh membacanya kapan saja, dengan kecepatan masing-masing.

Apache Kafka Adalah Catatan Peristiwa, Bukan Kotak Surat

Dokumentasi resminya menyebut Kafka sebagai event streaming platform (platform aliran peristiwa). Definisi praktisnya begini: Kafka adalah sistem yang menyimpan rentetan peristiwa secara berurutan dan tahan lama, lalu membiarkan banyak aplikasi membaca rentetan yang sama secara mandiri.

Perbedaannya dengan perantara pesan biasa terletak pada apa yang terjadi setelah pesan dibaca. Pada model kotak surat, pesan diambil lalu dihapus. Pada Kafka, pesan tetap berada di tempatnya sampai masa retensi habis. Catatan itu hanya bisa ditambah di ujung, tidak pernah disisipi di tengah, dan tidak berkurang karena dibaca.

Konsekuensinya besar. Kalau sistem analitik Anda salah menghitung selama tiga hari, Anda dapat memperbaiki kodenya lalu memerintahkannya membaca ulang dari tiga hari lalu. Data itu masih ada. Pada sistem yang menghapus pesan setelah dibaca, kesempatan itu sudah hilang.

Dokumentasi resmi merangkum tiga kemampuan inti Kafka: menerbitkan dan berlangganan aliran peristiwa, menyimpannya secara andal selama yang Anda mau, serta memprosesnya baik saat terjadi maupun secara surut.

Apache Kafka tidak ada hubungannya dengan Apache HTTP Server. Keduanya sama-sama proyek di bawah Apache Software Foundation, tetapi berbeda total. Apache HTTP Server adalah web server yang melayani halaman ke browser, sementara Kafka mengalirkan data antar aplikasi di belakang layar.

Enam Istilah Kunci di Balik Cara Kerjanya

Sebagian besar kebingungan tentang Kafka berasal dari istilahnya, bukan dari konsepnya. Enam istilah berikut sudah cukup untuk memahami arsitektur Apache Kafka secara utuh.

1. Event: satu catatan bahwa sesuatu telah terjadi. Isinya berupa kunci (key), nilai (value), penanda waktu, dan header opsional. Contohnya: "pengguna 771 membayar pesanan 4210 pada pukul 09.14".
2. Topik: nama wadah tempat peristiwa sejenis dikumpulkan, misalnya pesanan atau pembayaran. Satu topik boleh ditulis banyak pengirim dan dibaca banyak pembaca sekaligus.
3. Partisi: potongan dari sebuah topik yang tersebar di beberapa server. Peristiwa dengan kunci yang sama selalu jatuh ke partisi yang sama, sehingga urutannya terjaga. Partisi inilah yang membuat Kafka bisa diperbesar kapasitasnya. Nilai bawaannya num.partitions = 1, dan hampir selalu perlu dinaikkan.
4. Offset: nomor urut sebuah peristiwa di dalam partisi. Ini bagian terpenting yang sering terlewat. Offset dipegang oleh pembaca, bukan oleh server. Karena pembaca yang menentukan sudah sampai mana ia membaca, ia bebas mengulang dari posisi mana pun.
5. Producer dan consumer: penulis dan pembaca. Keduanya tidak saling mengenal dan tidak perlu hidup bersamaan. Beberapa consumer yang bekerja sama membentuk consumer group, dan tiap partisi dibagikan ke satu anggota group saja.
6. Broker dan replikasi: broker adalah server Kafka yang menyimpan data. Sebuah cluster terdiri atas beberapa broker, dan tiap partisi disalin ke beberapa broker sekaligus. Dokumentasi menyebut setelan produksi yang lazim adalah replication factor 3, artinya selalu ada tiga salinan data Anda.

Satu angka lagi yang perlu Anda tahu sejak awal: masa simpan bawaan adalah 168 jam alias tujuh hari (log.retention.hours). Lewat dari itu, data lama dibuang. Angka ini dapat dinaikkan, diturunkan, atau dibuat tak terbatas sesuai kebutuhan.

Susunan keenam istilah itu di dalam sebuah cluster kira-kira seperti berikut. Satu topik dipecah menjadi tiga partisi, dan tiap partisi punya satu pemimpin di sebuah broker plus salinan di broker lain.

Diagram arsitektur Apache Kafka: topik pesanan dibagi tiga partisi, tiap partisi punya broker pemimpin dan dua salinan.

Karena tiap partisi dipimpin broker yang berbeda, beban tulis tersebar rata ke seluruh cluster. Bila broker 2 mati, salinan partisi 1 di broker lain diangkat menjadi pemimpin baru, dan penulisan berlanjut tanpa campur tangan Anda.

Perjalanan Satu Peristiwa dari Producer ke Consumer

Cara paling mudah memahami cara kerja Apache Kafka adalah mengikuti satu peristiwa dari awal sampai akhir. Bayangkan pelanggan menekan tombol bayar.

Alur Apache Kafka: producer menulis ke topik pesanan, dua consumer group membaca dari offset 1204 dan offset 87.

Aplikasi pembayaran bertindak sebagai producer. Ia menulis satu peristiwa ke topik pesanan, dan Kafka menaruhnya di salah satu partisi berdasarkan kunci pesanan. Peristiwa itu langsung disalin ke broker lain sesuai replication factor, lalu dicatat permanen di disk.

Sejak titik itu, aplikasi pembayaran sudah selesai bekerja. Ia tidak menunggu siapa pun. Dua consumer group yang berbeda kemudian membaca topik yang sama secara terpisah. Group penagihan sudah sampai offset 1.204, sementara group analitik masih tertinggal jauh di offset 87 karena baru dinyalakan kembali setelah perbaikan.

Keduanya tidak saling mengganggu, dan tidak ada satu pun peristiwa yang hilang. Kalau besok tim Anda menambahkan sistem keenam, sistem itu bisa mulai membaca dari peristiwa paling awal yang masih tersimpan, tanpa satu baris pun perubahan di aplikasi pembayaran.

Ekosistem di Sekitar Kafka: Lima API dan Perkakasnya

Kafka jarang dipakai sendirian. Dokumentasi resmi membaginya menjadi lima antarmuka pemrograman, dan mengenali kelimanya membantu Anda tahu bagian mana yang sebenarnya Anda butuhkan.

1. Producer API dan Consumer API: dua pintu utama untuk menulis dan membaca peristiwa. Sebagian besar pekerjaan sehari-hari berhenti di sini.
2. Admin API: untuk mengelola topik, partisi, dan konfigurasi dari dalam kode, bukan lewat baris perintah.
3. Kafka Connect: kerangka siap pakai untuk memindahkan data dari dan ke sistem lain tanpa menulis kode consumer sendiri. Konektor untuk PostgreSQL, MySQL, Elasticsearch, dan penyimpanan objek sudah tersedia. Inilah yang biasanya dipakai untuk mengalirkan perubahan basis data secara berkelanjutan.
4. Kafka Streams: pustaka untuk mengolah aliran secara langsung, misalnya menghitung jumlah pesanan per menit. Ia berjalan sebagai bagian dari aplikasi Anda, bukan sebagai cluster pemroses terpisah.

Di luar kelima API itu, ada dua pendamping yang sering muncul dan kerap membingungkan pendatang baru. Schema Registry menyimpan definisi struktur pesan supaya pengirim dan penerima tidak berselisih format saat salah satu berubah. REST Proxy menyediakan jalur HTTP biasa bagi aplikasi yang tidak punya pustaka klien Kafka. Keduanya bukan bagian dari Apache Kafka sendiri, melainkan proyek pendamping dari ekosistem sekitarnya.

Soal pustaka klien, Java adalah warga kelas satu karena Kafka sendiri ditulis dengan Java dan Scala. Bahasa lain dilayani pustaka pihak ketiga yang sudah matang. Pengguna Python memakai confluent-kafka-python atau kafka-python, pengguna Go memakai franz-go atau sarama, dan pengguna Node.js memakai KafkaJS. Pemakai Spring Boot mendapat integrasi bawaan lewat Spring Kafka. Sebagian besar pustaka non-Java bertumpu pada pustaka C librdkafka.

Satu hal yang sering dicari pemula: Kafka tidak membawa antarmuka grafis apa pun. Pemantauan dan penjelajahan isi topik dilakukan lewat perkakas terpisah seperti AKHQ, Kafbat UI, atau Redpanda Console. Kalau Anda merasa ada yang kurang setelah menyalakan broker, memang begitu keadaannya.

Kafka Tanpa ZooKeeper: Yang Berubah Sejak Versi 4.0

Selama bertahun-tahun, menjalankan Kafka berarti menjalankan dua sistem sekaligus. Kafka menyimpan datanya sendiri, sementara metadata cluster — siapa broker aktif, siapa pemimpin tiap partisi — dititipkan ke Apache ZooKeeper. Dua sistem berarti dua konfigurasi, dua sumber kegagalan, dan dua hal yang harus dipantau.

Sejak Apache Kafka 4.0 yang rilis pada 18 Maret 2025, ZooKeeper dihapus sepenuhnya. Penggantinya adalah KRaft, mekanisme metadata milik Kafka sendiri yang berbasis protokol konsensus Raft. Sekarang metadata disimpan di dalam Kafka, dan mode KRaft menjadi satu-satunya cara menjalankan cluster.

Perubahan ini penting bagi Anda yang baru mulai, karena banyak materi pemasangan yang beredar masih menyuruh menyalakan ZooKeeper lebih dahulu. Langkah tersebut tidak lagi berlaku pada versi mana pun yang masih didukung hari ini.

Berikut status rilis per Agustus 2026 menurut halaman unduhan resmi:

Artinya seluruh lini 3.x, termasuk 3.9 yang menjadi versi terakhir pendukung ZooKeeper, sudah tidak lagi berstatus rilis yang didukung. Kalau Anda memelihara cluster lama, migrasi ke KRaft harus diselesaikan lebih dahulu sebelum bisa naik ke 4.x.

Perhatikan juga syarat Java. Broker, Connect, dan perkakas baris perintah membutuhkan Java 17 ke atas, sementara pustaka klien dan Kafka Streams masih menerima Java 11. Dokumentasi menyarankan Java 25 untuk pemasangan baru.

Apakah Kafka Sebuah Antrian? Jawabannya Berubah di Versi 4.2

Pertanyaan ini muncul terus-menerus, dan selama bertahun-tahun jawabannya adalah "bukan, meskipun mirip". Alasannya ada pada aturan consumer group. Dalam satu group, sebuah partisi hanya boleh dibaca oleh satu consumer. Jika Anda punya tiga partisi, jumlah pekerja paralel Anda mentok di tiga. Menambah pekerja keempat tidak menambah kecepatan apa pun, karena tidak ada partisi tersisa untuknya.

Pada antrian kerja sungguhan, sepuluh pekerja bisa berebut satu antrian yang sama dan tiap pesan cukup diselesaikan satu pekerja. Kafka tidak bekerja seperti itu. Karena itulah banyak tim memasang Kafka berdampingan dengan sebuah message broker (perantara pesan) klasik seperti RabbitMQ untuk keperluan yang berbeda.

Kondisi itu berubah lewat KIP-932, fitur yang dikenal sebagai share group. Perjalanannya bertahap: hadir sebagai akses awal di versi 4.0, berstatus pratinjau di 4.1, lalu dinyatakan siap produksi pada versi 4.2 yang rilis 17 Februari 2026.

Dengan share group, beberapa consumer dapat memakan isi satu partisi bersama-sama. Tiap record diakui satu per satu, percobaan pengiriman dihitung, dan ada tipe pengakuan RENEW untuk pekerjaan yang butuh waktu lebih lama. Singkatnya, Kafka kini bisa berperilaku sebagai antrian kerja tanpa meninggalkan model catatannya.

Perbedaan keduanya paling mudah dilihat berdampingan:

Satu partisi Kafka hanya dibaca satu consumer pada consumer group, tetapi dibagi beberapa consumer pada share group.

Perbedaan praktis dengan RabbitMQ tetap ada dan tetap penting. RabbitMQ unggul saat Anda membutuhkan aturan penyaluran pesan yang rumit ke banyak tujuan berbeda. Kafka unggul saat data yang sama perlu dibaca berkali-kali oleh banyak sistem, dan riwayatnya perlu disimpan.

Satu kekeliruan lain layak diluruskan di sini, yaitu menyandingkan Kafka dengan Apache Flink atau Apache Spark seolah ketiganya saling menggantikan. Keduanya bukan pesaing Kafka. Flink dan Spark adalah mesin pengolah aliran, sedangkan Kafka adalah tempat aliran itu mengalir dan tersimpan. Susunan yang lazim justru memakai keduanya bersamaan: Kafka membawa datanya, Flink atau Spark menghitungnya.

Pesaing Kafka yang sesungguhnya adalah perangkat lunak dengan peran sama. Apache Pulsar menawarkan pemisahan lapisan komputasi dan penyimpanan. Redpanda menyediakan implementasi ulang yang sepenuhnya kompatibel dengan protokol Kafka tanpa ketergantungan pada JVM. Amazon Kinesis dan Google Pub/Sub menawarkan layanan terkelola dengan model harga berbasis pemakaian. Bagi sebagian besar tim, ekosistem Kafka yang jauh lebih luas tetap menjadi alasan utama memilihnya.

Kapan Kafka Layak Dipakai — dan Kapan Sebaiknya Tidak

Kafka menyelesaikan masalah tertentu dengan sangat baik, dan memperumit masalah lain tanpa perlu. Empat pola berikut adalah wilayah yang benar-benar cocok untuknya.

1. Banyak sistem membutuhkan data yang sama: satu aliran pesanan dibaca oleh gudang, penagihan, notifikasi, dan analitik sekaligus. Menambah pembaca baru tidak menyentuh sistem penulis sama sekali.
2. Kecepatan menulis jauh melampaui kecepatan memproses: Kafka menampung lonjakan di disk, lalu pemroses menyusul dengan kecepatannya sendiri. Tanpa penampung ini, lonjakan trafik akan menjatuhkan layanan di hilir.
3. Pemindahan data berkelanjutan antar sistem: perubahan di basis data operasional dialirkan ke gudang data atau mesin pencarian secara terus-menerus lewat Kafka Connect, menggantikan tugas terjadwal yang berjalan semalam sekali.
4. Pemrosesan yang perlu diulang: perbaikan logika perhitungan dapat dijalankan ulang atas data historis, karena datanya memang masih tersimpan.

Sebaliknya, ada kondisi ketika memilih Kafka justru menambah pekerjaan tanpa imbalan. Kalau pembaca aliran Anda hanya satu atau dua sistem dan volumenya masih terukur dalam ratusan pesan per detik, Redis atau RabbitMQ menyelesaikan hal yang sama dengan pemeliharaan jauh lebih ringan.

Kafka juga bukan pengganti panggilan API yang menunggu jawaban. Saat pengguna menekan tombol dan harus melihat hasilnya seketika, panggilan langsung tetap jawabannya. Begitu pula kalau tujuan Anda sekadar menyimpan data untuk ditanyakan kembali — itu pekerjaan sebuah database, bukan Kafka.

Ada pula ambang perangkat keras yang sederhana. Karena setelan produksi yang lazim memakai tiga salinan data, cluster yang serius membutuhkan minimal tiga broker. Kalau anggaran Anda hanya cukup untuk satu server kecil, Kafka belum waktunya.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Kafka menuntut biaya yang nyata, dan sebagian besar biayanya bersifat operasional, bukan lisensi.

1. Beban pengelolaan yang tidak kecil: Anda memelihara sebuah cluster, bukan satu proses. Pemantauan, penyeimbangan partisi, dan perencanaan kapasitas disk menjadi pekerjaan rutin.
2. Kurva belajar yang curam: memahami offset, partisi, jaminan pengiriman, dan perilaku rebalance memerlukan waktu. Kesalahan pemahaman di sini berujung pada data terproses ganda atau terlewat.
3. Batas ukuran pesan: nilai bawaan message.max.bytes adalah 1.048.588 byte, sekitar 1 MB. Kafka memang dirancang untuk catatan kecil yang sangat banyak, bukan untuk berkas besar. Berkas gambar atau video sebaiknya disimpan di tempat lain, dan Kafka cukup membawa alamatnya.
4. Menyimpan data bukan berarti menjadi basis data: Kafka tidak menyediakan kueri berdasarkan isi. Anda membaca dari sebuah posisi lalu maju ke depan. Tidak ada padanan perintah untuk mencari satu baris tertentu.
5. Ekosistemnya masih bergerak: rilis 4.3 pada Mei 2026 sudah menandai beberapa komponen untuk dihapus di versi 5.0, termasuk modul streams-scala dan protokol rebalance consumer yang lama. Pemutakhiran berkala tetap menjadi bagian dari pekerjaan.

Kebutuhan Sistem untuk Menjalankan Kafka Sendiri

Bagian ini sering dilewati, padahal inilah yang menentukan apakah rencana Anda masuk akal. Dokumentasi resmi memberi angka yang cukup gamblang.

Mesin rujukan yang dipakai tim Kafka sendiri adalah server dengan dua prosesor Intel Xeon quad-core, RAM 24 GB, dan delapan disk SATA 7200 rpm. Untuk memperkirakan kebutuhan memori, dokumentasi menyarankan rumus sederhana: kecepatan tulis dikali 30 detik. Sisi JVM biasanya dijalankan dengan heap 6 GB memakai G1 garbage collector, konfigurasi yang di lingkungan produksi LinkedIn menghasilkan jeda sekitar 21 milidetik pada persentil 90.

Beberapa syarat sistem operasi juga tidak boleh diabaikan:

• File descriptor minimal 100.000 untuk proses broker. Nilai bawaan Linux jauh di bawah angka ini dan akan menyebabkan kegagalan begitu jumlah partisi bertambah.
• XFS lebih disarankan daripada ext4. Pengujian pada dokumentasi mencatat waktu tulis lokal sekitar 160 milidetik pada XFS, dibandingkan 250 milidetik ke atas pada ext4, dengan konsistensi yang lebih baik.
• Pasang opsi noatime saat me-mount disk, supaya sistem tidak menulis penanda waktu akses setiap kali berkas dibaca.
• Perhatikan vm.max_map_count yang bawaannya sekitar 65.535. Tiap segmen log memakan dua area pemetaan, sehingga jumlah partisi yang besar dapat menabrak batas ini.
• Gunakan Linux. Dokumentasi menyatakan Windows tidak didukung dengan baik.

Port bawaannya adalah 9092, sesuai nilai awal konfigurasi listeners. Angka ini menjelaskan mengapa Kafka mustahil dijalankan di hosting bersama: Anda membutuhkan hak akses root untuk membuka port non-standar, menyetel batas file descriptor, dan mengatur opsi mount. Untuk belajar dan lingkungan pengembangan, satu VPS dengan RAM 4 GB sudah memadai untuk menjalankan satu broker mode KRaft. Untuk cluster produksi tiga broker dengan disk cepat, dedicated server menjadi pilihan yang lebih masuk akal secara biaya maupun performa.

Semua angka di atas berlaku untuk server yang melayani beban sungguhan. Untuk sekadar belajar, kebutuhannya jauh lebih ringan, dan Anda dapat menjalankannya lewat Docker di komputer sendiri seperti pada bagian berikutnya.

Mencoba Kafka dalam Beberapa Menit

Membaca penjelasan tentang partisi dan offset akan jauh lebih masuk akal setelah Anda melihatnya bekerja. Cara tercepat adalah memakai image resmi, tanpa memasang Java atau mengunduh arsip apa pun ke sistem Anda.

Nyalakan satu broker mode KRaft di latar belakang dan petakan port 9092 ke komputer Anda:

docker run -d --name kafka -p 9092:9092 apache/kafka:4.3.1

Perkakas baris perintah Kafka berada di dalam container, pada direktori /opt/kafka/bin, dan direktori itu tidak masuk ke PATH. Karena itu setiap perintah dipanggil dengan jalur lengkapnya. Buat sebuah topik bernama pesanan:

docker exec -it kafka /opt/kafka/bin/kafka-topics.sh \
  --create --topic pesanan --partitions 3 \
  --bootstrap-server localhost:9092

Periksa hasilnya, dan Anda akan melihat ketiga partisi beserta broker yang memimpinnya:

docker exec -it kafka /opt/kafka/bin/kafka-topics.sh \
  --describe --topic pesanan --bootstrap-server localhost:9092

Sekarang tulis beberapa peristiwa. Tiap baris yang Anda ketik menjadi satu peristiwa terpisah, dan tekan Ctrl-C untuk berhenti:

docker exec -it kafka /opt/kafka/bin/kafka-console-producer.sh \
  --topic pesanan --bootstrap-server localhost:9092

Bagian yang paling layak Anda perhatikan ada di perintah berikut. Opsi --from-beginning menyuruh consumer membaca dari peristiwa paling awal yang masih tersimpan, bukan dari yang terbaru:

docker exec -it kafka /opt/kafka/bin/kafka-console-consumer.sh \
  --topic pesanan --from-beginning \
  --bootstrap-server localhost:9092

Jalankan perintah terakhir itu dua kali di dua jendela terminal. Keduanya akan menerima seluruh peristiwa yang sama dari awal, karena masing-masing memegang posisi bacanya sendiri. Inilah perilaku yang membedakan Kafka dari antrian yang menghapus pesan setelah diambil.

Setelah selesai bereksperimen, hentikan dan hapus container tersebut:

docker rm -f kafka

Perintah di atas disusun dari panduan quickstart resmi Kafka 4.3, dengan jalur /opt/kafka/bin yang diverifikasi langsung dari konfigurasi image apache/kafka:4.3.1. Panduan resmi menuliskan perintahnya sebagai bin/kafka-topics.sh karena mengasumsikan Anda mengunduh arsip Kafka ke komputer sendiri. Bila Anda memakai Docker, jalur lengkap dan docker exec seperti di atas yang berlaku.

Pertanyaan yang Sering Muncul

Apa fungsi Apache Kafka? Fungsi utamanya adalah menjadi penampung aliran peristiwa antar aplikasi. Kafka menerima data dari banyak penulis, menyimpannya secara berurutan dan tahan lama, lalu melayani banyak pembaca yang masing-masing berjalan dengan kecepatan sendiri.

Apa itu Kafka dalam IT? Dalam konteks teknologi informasi, Kafka merujuk pada Apache Kafka, perangkat lunak sumber terbuka untuk aliran peristiwa. Ia sering disebut sebagai message broker, meskipun sifat penyimpanannya membuatnya lebih tepat disebut platform aliran peristiwa.

Apakah Apache Kafka gratis? Ya. Apache Kafka berlisensi Apache 2.0 dan sepenuhnya open source, tanpa biaya lisensi. Yang berbayar adalah layanan terkelola dari pihak ketiga seperti Confluent Cloud atau Amazon MSK, serta biaya server yang Anda pakai sendiri.

Apakah Apache Kafka sama dengan Apache web server? Tidak. Keduanya proyek berbeda yang kebetulan bernaung di yayasan yang sama. Apache HTTP Server melayani permintaan halaman dari browser, sedangkan Kafka mengalirkan data antar aplikasi.

Kenapa namanya Kafka? Nama itu dipilih Jay Kreps, salah satu pembuatnya di LinkedIn. Alasannya, Kafka adalah sistem yang dioptimalkan untuk kegiatan menulis, sehingga memakai nama seorang penulis terasa masuk akal. Ia menyukai karya Franz Kafka sejak mengambil kelas sastra di bangku kuliah.

Apakah masih perlu belajar ZooKeeper untuk memakai Kafka? Untuk pemasangan baru, tidak perlu. Seluruh versi yang masih didukung berjalan dengan KRaft. ZooKeeper hanya relevan bagi Anda yang mewarisi cluster lama dan harus memigrasikannya.

Kesimpulan

Apache Kafka adalah platform aliran peristiwa yang menyimpan data sebagai catatan berurutan, sehingga banyak sistem dapat membaca aliran yang sama secara mandiri dan mengulangnya bila perlu. Kekuatannya terletak pada pemisahan antara penulis dan pembaca, ditambah kemampuan memutar ulang riwayat yang tidak dimiliki perantara pesan biasa.

Pakailah Kafka ketika beberapa sistem membutuhkan data yang sama, ketika volume tulis melampaui kecepatan pemrosesan, atau ketika riwayat data perlu dapat diproses ulang. Tunda dahulu bila pembaca Anda hanya satu atau dua dan volumenya masih ringan, karena beban pengelolaan cluster tidak sebanding dengan manfaatnya.

Bila Anda baru memulai hari ini, langsung saja ke versi 4.x dengan mode KRaft dan abaikan materi yang masih menyertakan ZooKeeper. Semoga artikel ini membantu.