Komunikasi Antar Service Menggunakan Kafka

Mengenal Publish dan Subscribe

Cara komunikasi antar service bisa ditempuh secara langsung maupun tidak langsung.

• Komunikasi langsung umumnya memakai RPC (Remote Procedure Call), dengan RESTful API sebagai pilihan paling populer saat ini. Pemanggil tahu persis dengan siapa ia bicara dan menunggu responsnya.
• Komunikasi tidak langsung memakai model messaging atau publish/subscribe. Cara ini membutuhkan aplikasi bernama "Message Broker" sebagai perantara — publisher mengirim data ke broker, dan subscriber mengonsumsinya sesuai ritme masing-masing.

Keunggulan utama Pub/Sub: publisher tidak perlu tahu apa pun soal siapa yang mengonsumsi datanya atau untuk apa. Ia hanya perlu memastikan datanya sampai di broker. Itu saja tugasnya.

Dengan komunikasi langsung, setiap kali ada service baru yang butuh data dari service lain, si produsen data harus ikut diubah — harus memberi tahu siapa, dalam format apa, ke endpoint mana. Keterikatan ini menumpuk setiap kali ada service baru di sistem.

Dengan message broker, konsumen baru cukup berlangganan ke topic yang relevan. Produsennya tidak disentuh sama sekali. Datanya mengalir seperti biasa.

Meski begitu, Pub/Sub bukan tanpa konsekuensi:

• Jeda. Karena komunikasinya tidak langsung, ada latensi antara saat pesan diterbitkan dan saat pesan diproses. Kalau subscriber lambat atau broker sedang berat, jeda itu jadi sulit diprediksi.
• Tidak ada umpan balik status bawaan. Secara default, publisher tidak punya cara untuk tahu apakah subscriber berhasil memproses sebuah pesan. Subscriber harus menangani sendiri logika retry dan kasus gagalnya.

Kenapa Kafka

Kafka adalah salah satu message broker yang paling banyak dipakai. Ia open source di bawah lisensi Apache 2.0, artinya bisa Anda pakai untuk keperluan pribadi maupun komersial tanpa biaya. Beberapa alasan ia menonjol:

• Skalabel. Kafka dirancang untuk menangani volume data yang sangat besar. Saat beban bertambah, Anda menskalakannya secara horizontal dengan menambah partisi dan broker.
• Throughput tinggi. Kafka memproses pesan dengan cepat dan konsisten, mengungguli banyak sistem sejenis dalam perbandingan benchmark.
• Persistensi. Kafka menyimpan pesan di disk, bukan hanya di memori. Kalau subscriber gagal di tengah pemrosesan, pesannya masih ada dan bisa diproses ulang.
• Ekosistem yang kaya. Kafka terintegrasi dengan Java, Python, Go, Node.js, C++, dan lainnya. Ia juga terhubung baik dengan infrastruktur data seperti Elasticsearch dan Apache Hadoop.

Konsep Dasarnya

Sebelum bisa memakai Kafka secara efektif, Anda perlu model mental yang jelas soal komponen-komponennya.

Topic

Topic adalah kanal bernama untuk satu kategori pesan. Producer menerbitkan ke sebuah topic; consumer berlangganan padanya. Anggap saja sebagai aliran data yang diberi nama secara logis — order-placed, payment-processed, user-registered.

Partisi

Setiap topic dipecah menjadi satu atau lebih partisi. Partisi adalah satuan paralelisme di Kafka. Pesan di dalam satu partisi terurut dan diberi offset berurutan. Antar partisi, urutan tidak dijamin — jadi kalau urutan itu penting, terbitkan pesan yang berkaitan ke partisi yang sama memakai key yang konsisten.

Broker

Broker adalah server Kafka. Sebuah klaster Kafka terdiri dari beberapa broker. Masing-masing broker memegang sebagian partisi dan menangani baca-tulis untuk partisi tersebut. Kalau satu broker mati, replika di broker lain menjaga data tetap tersedia.

Producer

Producer menerbitkan pesan ke sebuah topic. Ia bisa memilih ke partisi mana pesan dikirim — secara eksplisit, atau secara implisit lewat key (key yang sama selalu diarahkan ke partisi yang sama), atau round-robin bila tidak ada key.

Consumer dan Consumer Group

Consumer membaca pesan dari partisi sebuah topic dan melacak posisinya memakai offset. Consumer diorganisasi ke dalam consumer group. Di dalam satu group, setiap partisi ditugaskan ke tepat satu consumer — begitulah Kafka mencapai pemrosesan paralel tanpa pengiriman ganda. Group yang berbeda masing-masing menerima seluruh pesan secara independen, sehingga mudah membuat beberapa service mengonsumsi topic yang sama untuk tujuan berbeda.

Alur Pesan dalam Praktik

Contoh konkret: sistem e-commerce di mana pembuatan pesanan harus memicu pembaruan stok, email notifikasi, dan event analitik.

Dengan komunikasi langsung, service pesanan harus memanggil tiga service secara sinkron. Kalau salah satunya lambat atau mati, permintaan pesanan ikut melambat atau gagal.

Dengan Kafka:

1. Service pesanan menerbitkan satu pesan ke topic order-placed.
2. Service stok, service notifikasi, dan service analitik masing-masing berlangganan topic itu dalam consumer group-nya sendiri.
3. Masing-masing memproses pesan secara independen, dengan ritmenya sendiri, tanpa service pesanan perlu tahu atau peduli.

Service pesanan kini sepenuhnya terlepas. Menambah service hilir yang baru tidak menuntut satu pun perubahan pada produsennya.

Contoh Minimal dengan Go

Memakai pustaka segmentio/kafka-go:

// Producer
writer := kafka.NewWriter(kafka.WriterConfig{
    Brokers: []string{"localhost:9092"},
    Topic:   "order-placed",
})
writer.WriteMessages(ctx, kafka.Message{
    Key:   []byte(orderID),
    Value: []byte(orderJSON),
})

// Consumer
reader := kafka.NewReader(kafka.ReaderConfig{
    Brokers: []string{"localhost:9092"},
    Topic:   "order-placed",
    GroupID: "inventory-service",
})
for {
    msg, _ := reader.ReadMessage(ctx)
    processOrder(msg.Value)
}

ID consumer group inilah yang mengikat sebuah consumer ke riwayat offset-nya. Jalankan ulang prosesnya dengan group ID yang sama dan ia melanjutkan tepat dari posisi terakhirnya.

Kapan Kafka Bukan Jawabannya

Kafka menambah kerumitan operasional. Untuk sistem kecil dengan segelintir service dan trafik sedang, beban menjalankan dan mengelola klaster Kafka lebih besar daripada manfaatnya. Broker yang lebih sederhana seperti RabbitMQ, atau bahkan panggilan HTTP langsung, sering jadi pilihan yang tepat pada skala itu.

Kafka layak dipakai ketika Anda butuh throughput tinggi, penyimpanan pesan yang tahan lama, atau penyebaran ke banyak konsumen independen. Kalau belum satu pun kebutuhan itu berlaku, tetap sederhana saja dan ambil Kafka saat Anda benar-benar memerlukannya.

Ringkasnya

Kafka menyelesaikan masalah nyata: seiring sistem membesar, panggilan langsung antar service menciptakan jaring ketergantungan yang sulit diubah dan mudah patah. Model publish/subscribe memisahkan produsen dari konsumen dengan rapi, dan desain Kafka — log terpartisi, consumer group, persistensi di disk — membuat model itu andal dan skalabel.

Memahami topic, partisi, broker, dan consumer group sudah cukup untuk memulai. Sisanya adalah pengalaman operasional — menyetel replikasi, mengelola offset, menentukan jumlah partisi sesuai throughput Anda — yang datang seiring waktu.