Mengapa Harus RabbitMQ ? Contoh Studi Kasus dan Implementasi di Golang

Daftar Isi

Pernah ngga anda membayangkan ada sebuah restoran yang sangat ramai pool. Para customer service menerima pesanan dari pelanggan dan pastinya harus menyampaikan pesanan pelanggan ke dapur agar cepat di proses. Permasalahannya jika para pelayan harus mengantar pesanan pelanggan tersebut satu persatu ke koki, maka yang akan terjadi kemungkinan koki tersebut akan jadi kewalahan dan ada beberapa pesanan yang mungkin terlupakan. 

Lalu anda bayangkan jika restoran tersebut sudah menggunakan sistem antrian ( queue ) yang di mana setiap pesanan akan di catat dan di masukkan ke dalam antrean, lalu koki tersebut dapat mengambil pesanan itu kemudian memprosesnya secara urutan. Jadi jika menggunakan cara antrian ini, kemungkinan besar tidak akan ada pesanan yang terlupakan dan pastinya dapur yang kewalahan tadi dapat bekerja dengan lebih efisien dan tidak kelebihan beban pesanan. Nah konsep ini yang di gunakan oleh RabbitMQ dalam dunia software. 

RabbitMQ akan bertindak sebagai sistem queue ( antrean ) atau biasa di kenal dengan message broker yang dapat memastikan setiap pesanan pelanggan akan dikirim dan di proses dengan cara lebih terstruktur dan pastinya efisien buat sistem yang sudah besar. 

Pada artikel ini, saya ingin memberikan dan membahas tentang mengapa harus menggunakan RabbitMQ ? dan juga akan memberikan studi case yang simple agar teman-teman dapat lebih memahami tentang cara menggunakan RabbitMQ. 

Btw pada contoh code nantinya saya akan menggunakan golang ya. 

Mengapa Harus RabbitMQ ? 

Jadi sebenarnya ada beberapa message broker yang sudah populer juga ya. seperti ApacheKafka, ActiveMQ, dan NATS. dan pastinya ketiga message broker tersebut memiliki keunggulannya masing-masing. tapi ada beberapa alasan mengapa anda harus menggunakan rabbitmq, berikut saya detailkan alasannya di bawah ini : 

1.  Mendukung Banyak Bahasa Pemerograman

RabbitMQ sudah memiliki client library untuk berbagai bahasa pemerograman seperti java, golang, javascript dan masih banyak lagi. Sehingga jika anda membangun sistem dengan bahasa pemerograman java atau golang, anda tinggal install librarynya dan menggunakannya di project anda. 

2. Message Persistance

RabbitMQ mendukung fitur message persistance, yang artinya pesan akan dapat di simpan dalam disk sehingga jika terjadi kegagalan dalam sistem maka pesan tersebut tidak akan hilang. dan fitur acknowledgment and retry mechanism akan membantu memastikan pesan tidak akan hilang dalam proses pengiriman. 

3. Menggunakan Protokol AMQP

RabbitMQ menggunakan protokol AMQP (Advanced Message Queuing Protocol) yang dapat memungkinkan komunikasi pesan secara andal dan fleksibel. Konsepnya mungkin seperti ini ya : producer mengirim pesan ke antrian, dan consumer mengambil pesan tersebut.

Cuman ada 3 alasan nih yang saya bisa sebutkan mengapa hraus menggunakan RabbitMQ 😁. Jadi yaa pastikan anda tidak salah memilih message broker. karena ada beberapa message broker yang mungkin bisa menjadi pilihan tepat untuk project yang sedang anda kerjakan. So tidak harus menggunakan rabbitMQ ya 😁. 

Contoh Case dan Implementasinya di Golang

Jadi di sini saya akan memberikan contoh case sederhana jika tidak menggunakan message broker dan menggunakan message broker rabbitmq. dan saya akan menggunakan bahasa pemerograman golang sebagai pembuatan api sederhana untuk mengintergrasikan ke rabbitmq. 

Mari kita lihat case pertama jika anda tidak mengimplementasikan rabbitmq pada web application anda. 

Misal, saya akan mengambil contoh proses bisnis checkout product dan kita asumsikan arsitektur yang kita gunakan adalah arsitektur monolith : 

Apabila user melakukan proses request checkout, maka service akan menerima request tersebut dan akan memprosesnya serta mengolah data apa aja yang di butuhkan selama proses checkout. dan apabila berhasil, maka biasanya service akan mengembalikan sebuah response detail kepada user dan mengirimkan notifikasi ke email user. 

Yaaa mungkin program akan berjalan dengan lancar. Tapi pernahkah anda memikirkan bagaimana jika ada ratusan bahkan ratusan ribu user yang akan melakukan proses checkout dalam satu waktu ? Yaa pastinya checkout product service bisa saja kewalahan mengolah semua data secara syncrous bukan ?  dan ada kemungkinan proses tersebut tidak akan berhasil di karenakan beban yang di terima checkout service sangat banyak. Duarrr... akhirnya service tersebut down. 🙃

Nah solusi yang akan kita gunakan untuk mengatasi masalah di atas yaitu dengan menggunakan message broker yaa guys. RabbitMQ

Letsgo kita revisi gambar arsitektur sebelumnya dengan menggunakan pendekatan sistem antrian atau message broker.  

Mari saya jelaskan secara singkat alur kerja proses checkout yang sudah saya revisi.

Pertama-tama, web application akan mengirimkan request ke Checkout Product Service untuk memproses transaksi. dan setelah transaksi berhasil, Checkout Service akan memberikan response kembali ke Web Application yang berisi informasi keberhasilan transaksi.

Selain itu, Checkout Service juga akan mengirimkan (publish) pesan ke RabbitMQ Queue. Pesan ini bertujuan untuk memberi tahu Email Service agar mengambil dan memprosesnya.

Perlu di ketahui, di dalam sistem message broker seperti RabbitMQ, terdapat konsep Publisher dan Subscriber.

• Publisher merupakan layanan yang mengirimkan pesan ke Queue.
• Subscriber adalah layanan yang berlangganan ke Queue untuk menerima dan memproses pesan tersebut.

Dalam hal ini, Email Service bertindak sebagai subscriber. Layanan ini akan berjalan secara independen, mengambil pesan dari RabbitMQ Queue, lalu memprosesnya hingga email konfirmasi dapat dikirimkan kepada pengguna. Dengan pendekatan ini, pengiriman email berjalan secara async, sehingga tidak menghambat proses checkout utama di Web Application.

Nah mari kita ke tahap code nya guys 😁. 

BTW Di sini, saya akan menggunakan golang untuk mengimplementasikan RabbitMQ sesuai dengan arsitektur yang telah saya buat. dan penjelasan serta flow nya pun udah saya sisipkan ke dalam READMEE.md github nya ya. 

Kode sumbernya akan saya simpan di GitHub, jadi nanti kalian bisa cek langsung di sini : Link Github Nya

Semoga artikel ini bermanfaat dan dapat membantu dalam membangun sistem berbasis message queue yang lebih baik! 

Mari diskusi di kolom komentar jika ada yang keliru dari artikel saya atau penjelasan saya ya 😁.