Kafka sering menjadi topik pembicaraan dalam ekosistem teknologi Indonesia, terutama di perusahaan-perusahaan yang membangun pipeline data real‑time seperti Gojek, Tokopedia, dan BCA. Namun, sebagian besar panduan yang beredar hanya menjelaskan Kafka sebagai “log komit terdistribusi” atau “cepat karena I/O sequential disk”. Pemahaman dangkal ini memang cukup untuk memulai, tetapi tidak cukup untuk merancang, mengoptimalkan, atau memecahkan masalah produksi yang kompleks. Artikel ini membahas seluruh aspek internal Kafka – topologi, penyimpanan, replikasi, metadata kluster, jalur produsen, jalur konsumen, dan protokol jaringan – ditujukan bagi para profesional yang sudah memahami apa itu broker dan ingin mendalami bagian‑bagian yang benar‑benar membingungkan.
Pertama, model fisiknya. Broker adalah server fisik atau virtual yang memiliki CPU, RAM, disk, dan NIC – inilah unit hardware nyata dalam kluster. Topic adalah nama logis (misalnya “user-signups”) yang tidak pernah menjadi file di mana pun dan tidak berada di satu broker saja. Partition adalah unit penyimpanan sebenarnya: satu urutan append‑only dari record yang disimpan sebagai direktori pada disk broker tertentu dan direplikasi ke beberapa broker lain untuk ketahanan. Karena partition adalah unit fisik, skalabilitas Kafka bergantung pada seberapa banyak partition yang Anda bagi. Topik dengan satu partition hanya bisa berada di satu broker, tetapi partition sepuluh memungkinkan sepuluh mesin berbagi beban baca/tulis. Kepemimpinan juga diberikan per‑partition, bukan per‑topik atau per‑broker, sehingga broker seperti Broker 2 bisa menjadi pemimpin untuk partition 1 sekaligus pengikut untuk partition 0, mencegah terbentuknya hotspot.
Kedua, mesin penyimpanan menggunakan konsep segment, bukan pohon B‑tree. Tutorial sering menyebut partition sebagai “log append‑only”, tetapi jarang menjelaskan apa yang ada di dalamnya. Partition terdiri dari satu segmen aktif (yang terus ditulisi) dan beberapa segmen tertutup lama. Setiap segmen sebenarnya adalah tiga file dengan basis offset yang sama: file .log (record yang ditulisi secara berurutan, tidak pernah diubah), file .index (peta jarang offset → posisi byte dalam .log, hanya satu entri per beberapa KB), dan file .timeindex (peta timestamp → offset untuk pencarian berdasarkan waktu). Segment bergulir ketika ukuran log.segment.bytes tercapai atau log.roll.ms habis, yang berdampak pada operasi penghapusan, kompaksi, dan pemulihan broker.
Ketiga, kecepatan dan ketahanan. Baca cepat dimungkinkan dengan page cache dan zero‑copy, sementara tulis yang tahan lama dijamin oleh replikasi, bukan fsync. Desain ini mencerminkan prinsip utama Kafka: menolak akses acak. Konsumen tidak pernah meminta record tertentu; mereka hanya meminta “semuanya setelah offset N”. Batasan tunggal ini menentukan bentuk mesin penyimpanan, mengapa ketahanan adalah cerita replikasi, dan mengapa banyak mekanisme produsen/konsumen ada hanya untuk menangani edge case yang disebabkan oleh batasan tersebut.
Keempat, koordinasi. Broker harus sepakat tentang siapa yang hidup, siapa pemimpin, dan konfigurasi saat ini. Dalam mode KRaft, kuorum controller mengelola kepemimpinan secara terpisah dari Zookeeper, yang merupakan pendekatan lama. Metadata kluster didistribusikan melalui heartbeat broker dan pembaruan controller, sehingga perubahan seperti pergantian pemimpin partition dapat dipropagasi secara konsisten.
Kelima, kontrak klien. Pengaturan acks produsen menentukan seberapa banyak replika yang harus mengonfirmasi sebelum produksi dianggap sukses. Rebalancing grup konsumen menentukan bagaimana anggota membagi partisi di antara mereka ketika anggota baru bergabung atau anggota lama keluar. Mekanisme ini, meskipun terlihat seperti orkestrasi tingkat tinggi, sebenarnya adalah respons terhadap batasan “tidak ada akses acak”: semua pembagian dan penyeimbangan pada akhirnya bermuara pada manajemen offset dan pemimpin partition.
Keenam, di bawah kap mesin: protokol jaringan. API Produce, Fetch, OffsetFetch, dan GroupJoin adalah protokol yang mengikat seluruh lapisan di atasnya. Protocol ini memastikan bahwa produsen mengirim record langsung ke pemimpin partition, dan konsumen dapat melakukan sequential read, offset seek, atau time‑based seek dengan tepat. Pemahaman tentang protokol ini penting ketika Anda perlu menyesuaikan ukuran batch jaringan, menangani timeout, atau mengoptimalkan latensi.
Artikel ini tidak hanya menerjemahkan konsep‑konsep Kafka ke dalam bahasa yang lebih sederhana, tetapi juga menghubungkan teori‑teori tersebut dengan praktik‑praktik nyata yang dihadapi oleh insinyur Indonesia saat mereka membangun pipeline streaming yang skalabel dan tahan lama. Dengan memahami model fisik, mesin penyimpanan, dan koordinasinya, tim teknis dapat membuat keputusan yang lebih baik mengenai ukuran segment, faktor replikasi, dan konfigurasi grup konsumen – semua hal ini berdampak langsung pada biaya operasional dan keandalan layanan.
Mengapa ini penting bagi pembaca Indonesia? Pertama, banyak perusahaan startup dan perusahaan teknologi di sini sedang bertransisi ke arsitektur berbasis event-driven; pemahaman mendalam tentang Kafka akan mempercepat adopsi dan mengurangi kesalahan konfigurasi yang mahal. Kedua, pasar cloud lokal (seperti AWS, GCP, dan Azure) menyediakan layanan Kafka managed, tetapi optimisasi biaya dan performa tetap bergantung pada pengetahuan internal sistem. Ketiga, dengan berkembangnya komunitas developer di Jakarta, Surabaya, dan Bandung, sumber daya pendidikan yang membahas Kafka hingga tingkat ini akan membantu mencetak talenta yang siap menghadapi tantangan streaming skala global.
Dalam ekosistem teknologi yang semakin kompetitif, artikel ini menjadi panduan penting bagi para arsitek, operator, dan pengembang yang ingin melampaui tutorial dasar dan benar‑benar menguasai Kafka dari awal hingga akhir.