Belajar Apache Kafka - Sejarah, Latar Belakang & Mengapa Membutuhkan Event Streaming

#Pendahuluan

Sebelum menulis kode, kalian perlu tahu mengapa Kafka ada. Setiap teknologi lahir dari masalah nyata, dan Kafka lahir dari masalah data pipeline LinkedIn pada akhir 2000-an: bagaimana menghubungkan puluhan sistem yang memproduksi dan mengonsumsi data real-time tanpa membuat bottleneck di pusat.

Episode 1 ini akan membawa kalian memahami evolusi event streaming, masalah yang dipecahkan Kafka, bagaimana Kafka berbeda dari message broker tradisional, serta use case yang membuat Kafka begitu dominan. Pahami konteks ini, karena semua keputusan arsitektur di episode-episode berikutnya bersandar pada pemahaman ini.

Kita juga akan membandingkan Kafka dengan RabbitMQ, Amazon Kinesis, Apache Pulsar, dan Redis Streams. Perbandingan ini penting agar kalian tahu kapan sebaiknya memilih Kafka dan kapan teknologi lain lebih cocok.

#Evolusi Event Streaming

#Dari Traditional Messaging ke Event Streaming

Dunia messaging dimulai dengan broker seperti JMS dan ActiveMQ yang memindahkan pesan satu per satu antar aplikasi. Model ini bekerja untuk komunikasi point-to-point, tetapi tidak dirancang untuk memproses aliran data berkecepatan tinggi dalam skala besar. Satu broker tunggal menjadi bottleneck ketika volume pesan melonjak.

Event streaming mengubah paradigma: data diperlakukan sebagai aliran event yang tercatat permanen, dapat diputar ulang, dan dapat diproses banyak konsumen secara paralel. Alih-alih pesan "dikirim lalu dilupakan", setiap event disimpan dalam log yang terurut dan tahan lama.

#Kelahiran Kafka di LinkedIn (2011)

Pada 2008, LinkedIn menghadapi tantangan data pipeline yang rumit: sistem harus mengirim aktivitas pengguna ke banyak downstream system untuk analytics, search indexing, dan rekomendasi. Solusi mereka adalah sistem pub/sub sederhana, namun itu tidak menangani volume dan keragaman data yang terus tumbuh.

Jay Kreps, Neha Narkhede, dan Jun Rao membangun Kafka untuk menggantikan pipeline yang rapuh itu. Namanya terinspirasi dari penulis Franz Kafka, karena platform ini "mengoptimalkan untuk menulis" — seperti penulis novel yang produktif. Kafka menjadi open-source di Apache pada tahun 2011 dan keluar dari incubator pada 2012.

#Era Confluent dan Evolusi Ekosistem

Pada 2014, para pencipta Kafka mendirikan Confluent untuk membangun ekosistem di sekitar Kafka: Kafka Connect, Kafka Streams, ksqlDB, dan Schema Registry. Kemudian KRaft mode menghilangkan ketergantungan pada ZooKeeper, dan tiered storage membuka kemungkinan penyimpanan jangka panjang yang murah. Paradigma ini kini disebut event streaming.

#Masalah yang Diselesaikan Kafka

#Real-Time Data Pipeline dan Scalability

Sebelum Kafka, data pipeline berjalan secara batch (misalnya setiap malam) dan tidak bisa mengejar kebutuhan real-time seperti deteksi fraud atau monitoring. Kafka memungkinkan data mengalir dari sumber ke tujuan dalam hitungan milidetik, sekaligus menahan lonjakan volume dengan horizontal scaling: tambah broker, tambah kapasitas.

#Data Integration dan Replay Capability

Sistem perusahaan memakai banyak database dengan format berbeda. Kafka menjadi hub integrasi: satu sumber data menulis sekali, banyak sistem membaca. Yang membedakan Kafka dari queue biasa adalah replay capability — karena event tersimpan dalam log, konsumen baru bisa membaca ulang seluruh sejarah, atau konsumen lama bisa membaca ulang dari offset tertentu.

#Event Sourcing, CQRS, dan Stream Processing

Dengan log yang tahan lama, Kafka menjadi fondasi alami untuk event sourcing (menyimpan semua perubahan sebagai event) dan CQRS (memisahkan operasi baca dan tulis). Ditambah kemampuan stream processing — menganalisis dan mentransformasi data saat mengalir — Kafka memungkinkan arsitektur yang mustahil dengan database relasional tradisional.

#Kafka vs Traditional Messaging

#Kafka vs RabbitMQ

RabbitMQ adalah message broker klasik berbasis AMQP yang unggul dalam smart broker, dumb consumer: broker mengelola routing dan ACK secara ketat. Kafka justru dumb broker, smart consumer: konsumen mengelola offset-nya sendiri, sehingga throughput jauh lebih tinggi dan log dapat diputar ulang. Untuk task queue yang butuh routing rumit, RabbitMQ lebih cocok; untuk streaming throughput tinggi dan replay, Kafka menang.

#Kafka vs Amazon Kinesis

Kinesis adalah layanan managed untuk streaming di AWS, menggunakan konsep shard yang mirip partition. Kinesis lebih mudah dioperasikan karena terkelola penuh, tetapi Kafka memberikan portabilitas antar cloud/on-premise, harga yang lebih rendah pada volume besar, dan ekosistem tooling yang jauh lebih kaya.

#Kafka vs Apache Pulsar dan Redis Streams

Pulsar memisahkan storage dan compute dengan arsitektur layered storage native, serta mendukung multi-tenant yang lebih halus — cocok untuk perusahaan yang butuh isolasi tenancy ketat. Redis Streams adalah struktur data dalam Redis untuk streaming skala kecil sampai menengah; cepat dan sederhana, tetapi tidak menawarkan replikasi lintas cluster dan retention jangka panjang seperti Kafka.

#Core Use Cases Kafka

Berikut pola penggunaan Kafka yang paling umum di produksi:

• Real-time analytics dan monitoring: mengalirkan metrik aplikasi dan event bisnis untuk dashboard langsung.
• Log aggregation: mengumpulkan log dari banyak server ke satu pipa terpusat.
• Event sourcing: menyimpan semua perubahan state sebagai urutan event yang tidak bisa diubah.
• Komunikasi microservices: decoupling antar service lewat event, bukan request-response langsung.
• Stream processing: transformasi, agregasi, dan enrichment data saat bergerak.
• CDC (Change Data Capture): mereplikasi perubahan database ke sistem lain secara real-time.
• IoT data streaming: menampung telemetry dari jutaan perangkat.

producer -> [Kafka cluster] -> consumer 1 (analytics)
                            -> consumer 2 (search index)
                            -> consumer 3 (data lake)

Setiap konsumen membaca log yang sama dari offset-nya masing-masing, sehingga satu aliran event dapat melayani banyak beban kerja sekaligus — inilah inti kekuatan Kafka. Perhatikan pula bahwa semua tool Kafka mengandalkan flag --bootstrap-server untuk menemukan cluster, sebuah pola yang akan kalian temui di hampir setiap perintah sepanjang series ini.

#Praktik Cepat: Melihat Kafka Sekilas

Kalian belum perlu menginstal apa pun, tetapi melihat Kafka berjalan membantu memvisualisasikan semua konsep di atas. Cara tercepat adalah memakai image resmi Apache Kafka dalam mode KRaft single-node:

docker run --rm -p 9092:9092 apache/kafka:3.7.1

Perintah docker run apache/kafka:3.7.1 memulai satu broker sekaligus controller tanpa ZooKeeper. Tunggu sampai log menampilkan started (kafka.server.KafkaRaftServer), lalu buka terminal kedua dan verifikasi bahwa broker merespons klien:

bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092

Output menampilkan daftar versi protocol yang didukung broker beserta versi minimumnya. Tool kecil ini menegaskan poin besar episode ini: Kafka adalah sistem yang hidup — satu proses bisa langsung menerima tulis dari banyak aplikasi, dan seluruh ekosistem tooling-nya berkisar pada satu cara koneksi yang seragam sejak Kafka 2.x.

Jika docker run apache/kafka:3.7.1 terasa berat untuk mesin kalian, tidak masalah — di episode 3 kita akan membahas instalasi binary secara penuh beserta konfigurasi cluster multi-broker. Untuk sekarang, cukup pastikan kalian paham mengapa Kafka dirancang seperti ini, karena seluruh keputusan arsitektur berikutnya berdiri di atas pemahaman tersebut.

#Penutup

Di episode 1 ini kalian sudah memahami konteks historis dan problem statement Kafka: dari pipeline data LinkedIn yang rapuh, kelahiran Kafka pada 2011, hingga evolusi ekosistemnya menjadi platform event streaming. Kalian juga tahu perbandingan Kafka dengan RabbitMQ, Kinesis, Pulsar, dan Redis Streams, serta use case utama yang melatarbelakangi hampir semua penerapan di dunia nyata.

Inti yang harus dibawa pulang:

• Kafka lahir dari masalah data pipeline LinkedIn: menghubungkan banyak sistem tanpa bottleneck.
• Event streaming berbeda dari traditional messaging karena event tersimpan permanen dan bisa di-replay.
• Kafka memakai model dumb broker, smart consumer: konsumen mengelola offset sendiri.
• RabbitMQ unggul di task queue, Kafka unggul di throughput dan replay.
• Use case inti Kafka: real-time analytics, log aggregation, event sourcing, microservices, stream processing, dan CDC.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur Apache Kafka — struktur event, topic dan partition, producer dan consumer, broker dan cluster, offset dan consumer group, hingga model distributed commit log serta peran controller broker. Pastikan kalian sudah paham konteks historis ini, karena fondasi konsep akan kita bangun secara detail berikutnya!