Pendahuluan

Pendahuluan awal mengenai Kafka dilihat di Kafka - Part 1 ?

Streaming artinya proses pengiriman data secara terus-menerus

Kenapa kita perlu memakai Kafka ?

Tidak ada yang mengharuskan kita memakai Kafka sih.

Pakai messaging platform seperti ActiveMq, RabbitMq, dan mq-mq lainnya juga sudah cukup sebenarnya kalau cuma untuk pemrosesan data asinkronous.

Wong biasanya kita hanya butuh biar bisa pemrosesan datanya nggak ke-blocking saja karena harus diproses dan menunggu response oleh proses selanjutnya.

Dan biasanya juga pemrosesan asinkronous juga dilakukan karena pemrosesan dilakukan dengan proses yang terpisah saja kok.

Sepertinya terlalu berlebihan kalau semuanya harus pakai Kafka.

Contohnya :

  • Aplikasi yang cuma CRUD (Create Read Update Delete) saja, kalaupun mau memakai asinkronous yang tidak usah pakai Kafka, pakai traditional messaging saja sebenarnya cukup.
  • Aplikasi integrasi sederhana dengan aplikasi lain. Ini juga juga bisa pakai messaging platform biasa/tradisional.
  • Aplikasi batching data sederhana pakai scheduler juga pakai platform messaging biasa juga cukup.

Lalu, sebenarnya bagaimana dan apa aplikasi yang harusnya yang perlu kita gunakan Kafka ?


Kata kuncinya adalah streaming

Streaming artinya proses pengiriman data secara terus-menerus

hmm, maksudnya ?

maksudnya kalau aplikasi kita itu berkarakteristik seperti berikut :

  • merupakan aplikasi yang didalamnya terdapat aliran data terus menerus tanpa henti.
  • mempunyai flow yang saling terkait satu sama lain dengan data yang saling berpindah-berpindah.
  • berfokus kepada history of data dan pengukuran/metriks.
  • berfokus kepada monitoring, dan pengelolaan data real time.
  • mengambil data aktivitas atau event, seperti aktifitas audit trail, security event, dll.
  • berusaha melakukan proses aggregasi, enrichment, transformasi data secara terintegrasi dengan messaging sistem.

Secara umum, fungsi Kafka lebih terpakai untuk menangani volume data yang besar, data butuh diproses secara parallel, sistem yang cukup kompleks melibatkan banyak proses dan monitoring.

Kelebihan kafka ini ditunjang dengan kemampuan skalabilitas dan high availibility nya.

Sehingga data yang besar bisa dipecah dengan konsep partisi, data yang masuk juga bisa direplikasi di server yang berbeda di cluster yang sama.


Tapi apakah Kafka bisa digunakan untuk tradisional messaging juga ?

Tentu saja ..

Kalau secara sederhana Kafka itu adalah kombinasi dari :

  • messaging systems (publish subscribe)
  • distributed storage
  • processing data

Sehingga Messaging System juga merupakan bagian dari sistem Kafka itu sendiri.

Tentunya menggunakan Kafka sebagai messaging platform juga tidak salah, karena memang Kafka dibuat untuk hal itu juga.

Berpikir secara reactive dibandingkan imperative ..

Memiliki sistem dengan menggunakan Kafka sebagai event streaming, membuat kita berpikir lebih Reactive dibandingkan Imperative

Imperative

Berpikir Imperative adalah strategi pertama kali kita ketika berhadapan dengan kasus apapun dalam dunia software engineering.

Berpikir bahwa setelah kejadian A, maka perlu dilakukan aksi B, kirim data ke repository C, dll.

Sebuah data, event, atau kejadian yang masuk ke sebuah messaging system, dianggap harus mempunyai aksi tambahan yang terikat kepada event tersebut.

Ada tahapan-tahapan yang dilakukan secara imperative, yang biasanya dikirimkan sebagai perintah/command dari sebuah proses.

Misalnya sebuah klik tombol submit di sebuah web, ketika itu pula kita memastikan bahwa ada aksi untuk submission yang harus dilakukan, baik melalui aksi sinkronous atau asynchronous dibelakangnya.

Termasuk didalamnya kalau kita berpikir asynchronous.

Hal yang natural dan wajar.

Reactive

Berpikir Reactive adalah berpikir bagaimana merespon sebuah kejadian, terutama dalam bentuk data yang terus-terusan berubah.

Sebuah kejadian, data atau event bisa di maknai berbeda oleh tiap-tiap domain yang menanganinya.

Artinya misalnya ketika sebuah perubahan di database terjadi, kemudian dilakukan pemrosesan asynchronous, maka tergantung dari domain yang peduli dan subscribe terhadap perubahan itu untuk melakukan sebuah tindakan.

Contohnya di sebuah perubahan status pembayaran di sistem e-commerce.

Ketika domain payment yang menerimanya, mungkin saja akan dilakukan proses pembayaran menjadi Paid.

Akan tetapi ketika domain Delivery yang menerimanya, mungkin saja akan dilakukan pemanggilan kirim order ke sistem delivery pihak ketiga.

Atau ketika domain Order yang menerimanya, maka akan dilakukan pengurangan data jumlah stok barang.

Semua domain tersebut bereaksi terhadap data/event/kejadian yang sama.

Berpikir Reactive memungkinkan kita untuk berpikir secara loosely coupled baik terhadap code dan pemrosesan yang kita lakukan.

Misalnya dengan contoh data yang sama seperti diatas, kita punya 3 subscriber yang saling tidak tahu satu sama lain, tetapi masing-masing memproses data sesuai dengan kepentingannya masing-masing.

Traditional messaging sebenarnya mensupport hal ini melalui mekanisme publish-subscribe ke sebuah topic juga, akan tetapi diawal-awal implementasinya, hanya satu subscriber yang akan bisa memproses message nya itu.

Semenjak spesifikasi JMS 2.0, maka dimungkinkan sebuah message bisa diproses oleh banyak consumer.

Kafka dari awal memang didesain dengan konsep multiple consumer, high available, dan distributed storage.

Sehingga Kafka cocok dengan konsep berpikir Reactive seperti diatas.

Okeh. Kita akan lanjut part 3.