Event Aggregate Platform di Blibli.com
Seperti yang pernah saya bahas di publikasi sebelumnya tentang Event-Driven Architecture. Saat ini Blibli.com memilih arsitektur Event-Driven dalam membangun sistem nya. Namun tahukah ada satu masalah yang tidak dibahas pada publikasi tersebut?
Apa yang terjadi jika ada sebuah service yang membutuhkan data aggregate dari beberapa service?
Hal yang bisa kita lakukan jika ada sebuah service yang membutuhkan data aggregate dari beberapa service adalah, dengan melakukannya secara manual di service tersebut. Namun apa yang terjadi jika beberapa service memerlukan aggregate yang sama? Alhasil kita harus menduplikasi fitur tersebut di semua service yang membutuhkan. Dan itu bukanlah solusi yang menarik sepertinya.
Event Aggregate Platform
Dari permasalahan ini, maka di Blibli dicetuskan ide untuk membuat sebuah Aggregate Platform, dimana platform ini akan menjadi tempat untuk melakukan proses aggregate yang nanti dibutuhkan oleh service-nya. Ide Aggregate Platform ini sendiri diambil dari salah satu Enterprise Integration Pattern, yaitu Aggregator pattern.
Aggregator Platform akan mengambil seluruh event yang ingin di aggregate dari Kafka. Semua event di kirim dalam bentuk JSON dan di simpan di MongoDB dan Elasticsearch untuk diolah oleh Aggregate Platform.
Proses aggregate di Aggregate Platform dilakukan pada saat menerima data event. Artinya tidak dilakukan pada saat query data. Hal ini dilakukan agar proses query data lebih ringan, karena aggregate sudah dilakukan di awal ketika data event diterima.
Arsitektur Event Aggregate Platform
Secara garis besar, arsitektur Aggregate Platform cukup sederhana. Aggregate Platform hanya butuh menangkap semua event yang di publish ke Kafka oleh service, lalu menyimpannya di MongoDB dan Elasticsearch. Jika ada service yang butuh melakukan proses aggregate, maka tim service tersebut akan membuat module yang bisa di sisipkan dalam Aggregate Platform.
Aggregate Platform sendiri dibagi menjadi 2 service, Aggregate service dan Query service. Aggregate service bertugas untuk menangkap semua event dan melakukan proses aggregate terhadap event tersebut. Sedangkan Query service digunakan sebagai API untuk melakukan proses pengambilan data domain dan hasil aggregate.
Kenapa dipisah? Tidak digabung saja? Alasannya adalah agar jika terjadi perubahan atau ada masalah di Aggregate service, service yang butuh mengambil data masih tetap bisa berjalan dengan menggunakan Query service.
Sebagai CQRS Platform
Selain memiliki kemampuan untuk melakukan proses aggregate, Aggregate Platform juga kita gunakan sebagai CQRS platform. Semua domain event akan di simpan di MongoDB dan Elasticsearch, sehingga Query service di Aggregate Platform dapat digunakan sebagai pengganti Query module untuk tiap service.
Dengan menggunakan Aggregate Platform, secara otomatis service tidak perlu lagi untuk membuat Read API dan Search API. Hal ini dikarenakan jika ada service lain yang ingin mengambil data, cukup dengan menggambilnya melalui Query service-nya Aggregate Platform. Tak perlu lagi ada proses development tambahan yang dilakukan di service masing-masing untuk membuat Read API dan Search API.
Sebagai Audit Table
Pada Aggregate Platform, kita juga menambahkan fitur untuk menyimpan riwayat perubahan yang terjadi pada tiap domain yang ada di Kafka. Setiap perubahan akan disimpan di Elasticsearch. Hal ini berguna bagi service yang memang butuh untuk menyimpan riwayat perubahan dari data event nya.
Dengan menggunakan fitur ini, service yang ingin menyimpan data riwayat atau audit, tidak perlu melakukannya secara manual lagi di service-nya. Cukup memberi tahu Aggregate Platform untuk menyimpan seluruh perubahan data dari event yang dikirim ke topic di Kafka, dan secara otomatis tiap riwayat perubahan akan di simpan di Aggregate Platform.
Modular
Aggregate Platform didesain dari awal se-modular mungkin. Hal ini dikarenakan module-module yang akan digunakan untuk melakukan proses aggregate akan dikerjakan oleh tim service yang membutuhkan proses aggregate tersebut.
Setiap tim service bisa membuat module aggregate masing-masing sesuai kebutuhkan, setelah module nya selesai, module tersebut akan dimasukkan ke dalam Aggregate Platform, dan secara otomatis akan dijalankan.
Kami menggunakan kemampuan auto configuration-nya Spring Boot untuk membuat system yang modular tersebut. Kita memilih menggunakan fitur yang terdapat di Spring Boot ini dikarenakan agar mempermudah para software engineer di Blibli.com, karena memang yang sudah terbiasa menggunakan teknologi Spring Framework.
Berikut saya bagikan video tentang Event Aggregate Platform yang di presentasikan oleh Sekar Anglila, salah satu R&D Engineer di Blibli.com yang berkontribusi besar dalam pembuatan Event Aggregate Platform ini.
We Are Hiring for Blibli.com Bandung and Jakarta
Tertarik untuk bergabung menjadi keluarga besar Blibli.com Jakarta atau Bandung? Silahkan submit CV Anda ke halaman karir Blibli.com di https://www.blibli.com/page/karir/
Atau jika tertarik ngobrol-ngobrol dulu, Anda bisa hubungi saya Eko Kurniawan Khannedy via email eko.k.khannedy@gdn-commerce.com.
