CQRS
Command Query Responsibility Segregation
Pertama kali mendengar istilah CQRS pattern, saya merasa seolah-olah kata tersebut tidak asing lagi dan sering digunakan. Setelah banyak membaca dan mempelajari penjelasan mengenai pattern CQRS ini, ternyata selama ini saya sudah sangat sering menggunakannya tanpa mengetahui jenis patternnya tersebut. Walaupun, kita secara tidak langsung atau tidak sengaja telah menerapkan pattern ini, alangkah baiknya kita mengetahui best praktis dan kapan kita disarankan menggunakan pattern ini.
CQRS sendiri sudah lama dicetuskan oleh Greg Young. Pattern ini merupakan jenis arsitektur pattern yang membagi antara proses penulisan (action command) dan pembacaan data dalam proses serta service yang berbeda.
Pada microservice arsitektur, data tersimpan dibeberapa database yang berbeda baik nama ataupun jenis databasenya. Misalkan, database User pada MongoDB atau database Neraca pada MySql. Hal ini mengakibatkan proses pengambilan atau pencarian data membutuhkan effort yang tidak mudah dan mungkin sangat berat dan lama dalam proses developmentnya.
Apabila kita menggunakan teknik yang umum, seperti data diambil dari masing-masing service, lalu data tersebut kita gabungkan di level code, dan terakhir baru ditampilkan maka respon time dan performance pencarian data tersebut akan turun dan sangat lambat.
Solusi kita dapatkan dengan menggunakan CQRS pattern pada aplikasi atau system yang kita buat. Dengan membuat database tersendiri seperti database view yang bersifat read only serta membuat satu service yang berbeda untuk menghandle database maka kita akan dapat meningkatkan performa dari proses pencarian.
Database yang kita buat ini merupakan agregator dari beberapa service yang terlibat dan biasanya kita menerapkan aturan denormalisasi pada tabel-tabelnya. Dengan demikian, proses pencarian data menjadi lebih cepat, scalable, dan akhirnya akan meningkatkan performance keseluruhan dari proses pencarian data.
Secara diagram, contoh dari penerapan CQRS pattern dapat digambarkan sebagai berikut.
Dari gambar di atas terlihat bahwa Order History service merupakan agregator dari semua service-service yang terlibat dalam proses pemesanan dari awal sampai akhir.
Umumnya permasalahan utama dari CQRS adalah cara kita memproses semua data yang datang secara cepat dan benar. Karena terkadang data yang datang itu banyak dan secara serempak bersamaan yang akhirnya mengakibatkan proses mengolahan data dan menyimpannya ke database menjadi lama bahkan mungkin terjadi blocking.
Cara yang paling tepat adalah dengan menggunakan teknik pemrosesan data secara asynchronous dan ditriger oleh event (event base). Penjelasan mengenai komunikasi secara event base, dapat dipelajari dari artikel yang berjudul Service Komunikasi pada Microservice.
Messaging adalah teknologi utama yang wajib kita gunakan pada CQRS pattern ini. Selain messaging, kita harus menentukan juga mengenai jenis penyimpanan database yang tepat untuk kita gunakan sebagai agregator service. Biasanya cahce teknologi seperti redis atau serach engine database seperti elasticsearch merupakan pemilihan yang tetap. Hal ini kerena kedua jenis databse tersebut memang sudah di rancang untuk keperluan pencarian data yang lebih cepat dan scalable.
Lebih detil mengeai CQRS tesebut bisa di jelaskan oleh gambar berikut.
Timbul pertanyaan apakah semua service yang kita miliki harus menggunakan CQRS? Jawabannya adalah tidak. Kita akan menggunakan CQRS untuk proses-proses atau service yang telah kita perhitungkan akan banyak di akses oleh user dan membutuh kan performance yang handal. Contoh service-serivice yang lansung diakses oleh umum atau client kita. Misalkan service yang meng- handle customer facing atau pencarian data pada sistem kita.
Berikut adalah digaram secara detil dari CQRS implementasi
Suatu pendekatan yang kurang tepat jika CQRS menggunakan pendekatan scheduler untuk melakukan pooling data dari service-serivce yang terlibat. Misalkan setiap 5 menit sekali agregator mengambil data-data dari semua service yang terlibat. Kenapa kurang tepat karena pertama data akan kurang uptodate dan kedua pemrosesan data akan sangat lama jika data yang kita miliki sudah sangat banyak.
Secara arsitektur umumnya CQRS ini akan berkolaborasi dengan event sourcing pattern yang akan kita bahas pada penjelasan selanjutnya.
IT Training
Mau improve skill IT dan pemrograman Anda, Silahkan cek jadwal training berikut.
Kaos Pemrograman
Membutuhkan kaos dengan tema pemrograman :
Dapat menghubungi The Legend
