Apa Itu Message Broker
Sebelumnya saya telah menulis tentang arsitektur monolitik dan microservices pada sebuah aplikasi atau sistem. Seperti yang saya tunjukkan sebelumnya bahwa pada arsitektur microservices, sistem dijalankan oleh banyak service terpisah. Service-service ini saling bertukar data atau message sehingga proses dalam sistem tersebut dapat dijalankan.
Pertukaran data ini dapat dilakukan secara langsung antar service. Kita ambil contoh sederhana sistem informasi di sebuah rumah makan dimana ada tiga 'komputer' masing-masing satu untuk order, kitchen, dan kasir. Data pesanan masuk dari pelanggan akan dikirimkan dari service Order ke service Kitchen untuk dasar penyajian makanan dan service Kasir untuk tagihan pembayaran.
Nah sekarang flow transaksinya menjadi jauh lebih rumit. Service yang terlibat bertambah, secara otomatis koneksi antar service pun semakin banyak. Ditambah lagi sekarang dari Kitchen F & B ada kebutuhan untuk mengirim data ke Order untuk memberi tahu jika ada bahan/menu yang habis. Sehingga sekarang selain koneksi bertambah, arah pengiriman data juga bisa bolak balik.
Flow yang rumit seperti ini biasa disebut spaghetti flow. Banyak kelemahan dari flow yang sudah terlalu semrawut ini. Pertama sulit untuk dimaintain atau diperbaiki jika ada masalah, rawan error atau data hilang di tengah jalan, dan sulit dilakukan pengembangan. Bayangkan jika rumah makan semakin besar dan ingin menambah Kitchen Food yang kedua, maka semua service Order akan terkena imbasnya (harus ikut diupdate padahal tidak ada kesalahan).
Induk dari kebanyakan masalah ini adalah keterikatan antar service. Message Broker hadir untuk menyelesaikan masalah ini. Message broker merapikan proses pertukaran data sehingga lebih mudah dimaintain, dimonitor, dan dikembangkan. Message broker melakukan de-coupling, memisahkan masing-masing service sehingga perubahan/pengembangan di salah satu service tidak berdampak signifikan pada service lain. Berikut jadinya ketika Message Broker digunakan
Sekarang service Order tidak perlu mengirim datanya langsung ke Kitchen, Admin, dan Kasir. Instead, Order cukup meletakkannya di Message Broker. Di sisi penerima, Kitchen, Admin, dan Kasir tinggal ambil data yang sudah ditaruh di Message Broker. Tidak ada hubungan langsung antara pengirim dan penerima. Message Broker bagaikan loker tempat menaruh dan mengambil sesuatu. Perhatikan pula bahwa semua panahnya bolak-balik, artinya satu service bisa berperan sebagai pengirim dan penerima sekaligus.
Untuk lebih memperjelas lagi, message broker ini bisa dianalogikan sebagai jasa kurir pengiriman. Bayangkan kita mau kirim undangan ke 100 orang. Tanpa ada jasa kurir, kita perlu mendatangi 100 orang itu satu per satu. Dengan adanya kurir kita cukup datang ke satu tempat saja, begitu undangan kita serahkan ke kurir, ya sudah.
Di sisi penerima bayangkan kita membeli 25 barang di marketplace dari seller yang berbeda-beda. Lebih enak mana kita menunggu dan membukakan pintu untuk satu-satu seller datang membawakan barang yang kita beli di waktu yang berbeda-beda, atau kita menunggu satu kurir saja teriak pakeeet sambil bawa tumpukan segunung barang yang kita beli?
Konsep message broker seperti ini lah yang digunakan oleh Apache Kafka. Kafka adalah salah satu product message broker yang sekarang ini banyak digunakan di berbagai bidang. Dalam Kafka, pengirim disebut Producer, penerima disebut Consumer, dan data disimpan dalam kotak-kotak yang disebut Topic. Saya akan menjelaskan seputar Apache Kafka ini pada bagian berikutnya.
Sekian.
