Saga Pattern
Data Management dan Transaksional pada Microservice
Pada artikel sebelumnya telah dijelaskan mengenai Data per Service yang merupakan bagian dari Data Management pada Microservice. Selanjutnya kita masuk ke penjelasan jenis yang kedua yaitu, Saga Pattern.
Seperti yang telah kita ketahui, konsistensi data pada database merupakan hal yang paling penting dalam setiap aplikasi. Transaksional adalah cara yang biasa digunakan sebagai solusi untuk menjaga konsistensi data tersebut.
Pada sistem Monolith, aturan yang selalu digunakan adalah two phase commit. Cara ini mengharuskan semua proses yang terjadi seperti, insert, update, delete, atau gabungan ketiganya pada dua tabel atau lebih harus commit secara bersamaan atau rollback bersamaan. Intinya data harus terproses semua atau tidak sama sekali.
Berbeda ceritanya pada sistem Microservice. Karena tabel-tabel berada pada database yang berbeda-beda dan satu tabel dimanage hanya oleh satu service maka konsep two phase commit tidak bisa kita gunakan lagi. Saga Pattern adalah konsep yang dapat menjawab konsistensi data pada microservice.
Saga Pattern sendiri sebenarnya sudah lama dipublikasi sejak tahun 1987 dan sekarang ini ramai lagi digunakan pada microservice arsitektur. Misalkan terdapat sebuah arsitektur sistem e-commerce seperti pada gambar di bawah ini.
Terdapat minimal empat service yang terlibat dalam suatu proses order. Contoh kasus lain adalah proses order pada aplikasi management hotel atau foodmarket. Proses order yang terjadi dapat digambarkan sebagai berikut.
Pada proses diatas, proses order akan melakukan pencarian data dari table consumer melalui service consumer dan setelahnya menulis data sekaligus ke table kitchen dan accounting melalui service nya masing-masing. Pada kasus microservice atau monolith, menghandle konsistensi data seperti yang tergambar di atas sangat lah sulit. Hal ini terjadi karena table-table berada di database yang terpisah.
Pendekatan distribusi transaksi atau lebih dikenal sebagai global transaksi pun tidak dapat bekerja dengan benar untuk kondisi dimana kita menggunakan database modern yang bersifat non transaksional dalam skala global transaksi seperti, mongodb atau cassandra. Catatan bahwa beberapa jenis nosql sudah support two phase commit salah satu contoh nya mongodb sendiri.
Adapun, untuk database jenis transaksional atau RDBMS dan tabel-table nya terpisah, menjaga konsistensi data masih bisa dilakukan melalui global transaksi . Hal ini bisa dilakukan karena jenis databasenya telah support xa- transaksi.
Selain itu, sistem-sistem yang menggunakan message broker modern yang sekarang banyak di gunakan, ternyata tidak support juga terhadap distribusi transaksi termasuk di dalamnya rabbitmq dan kafka.
Problem lainnya pada distribusi transaksi, prosess di lakukan secara synchronous, sehingga jika aplikasi di hit dengan jumlah user yang banyak, proses synchronous akan menurunkan tingkat availability serta performance dari Aplikasi. Dengan demikian, distribusi traksaksi tetaplah bukan solusi terbaik.
Saga Pattern
Saga adalah urutan transaksi lokal di mana setiap transaksi berjalan pada sistem local masing-masing service. Transaksi pertama dimulai oleh permintaan eksternal yang sesuai dengan operasi sistem dan kemudian setiap langkah berikutnya dipicu oleh penyelesaian proses yang sebelumnya.
Apabila kita terapkan pada kasus e-commerce di atas maka proses order yang sudah menerapkan saga pattern menjadi seperti gambar berikut.
Terdapat berbagai cara untuk mengimplementasikan saga pattern. Akan tetapi, yang lebih banyak dipergunakan adalah event koreografi dan command orkestrasi.
Event atau Koreografi
Pada saga dengan implemantasi event ciri utamanya adalah proses tidak memiliki central atau pusat dari sistem. Setiap service menghasilkan dan mendengarkan event serta memutuskan apakah suatu tindakan harus diambil atau tidak.
Saga pattern pada jenis ini akan berakhir jika service terkahir yang terlibat melakukan transaksi lokal dan tidak ada publish event apapun yang di dengar oleh setiap service yang terlibat pada saga.
Apabila kita gambarkan proses koreografi ini dapat kita liat seperti gambar barikut.
- Order Service menyimpan data order baru dan menentukan state atau status pending dan sekaligus publish event dengan nama, misalkan ORDER_CREATED.
- Payment Service mendengarkan event ORDER_CREATED, melakukan debet pada client, dan mempublish event BILLED_ORDER. Pada proses ini triger bisa di datangkan juga dari proses pembayaran yang di lakukan client.
- Stock service mendengarkan event BILLED_ORDER, melakukan update stock, melakukan persiapan untuk pengiriman product yang di beli, dan mempublish event ORDER_PREPARED
- Delivery Service mendengarkan event ORDER_PREPARED melakukan pengambilan dan mengirimkan product. Apabila telah selesai dia akan mempublish ORDER_DELIVERED.
- Akhirnya, Order Service mendengar even ORDER_DELIVERED dan mententukan state dari order telah beres di jalankan atau dengan kata lain keseluruhan order FINISH.
Pada kasus di atas, apabila kita berkeingininan untuk melakukan track dari semua proses yang terjdi, bisa dilakukan dengan mudah yaitu Order Service akan mendengarkan semua event dan melakukan update dari setiap state atau status yang terjadi.
Rollback Sistem pada Event Koreografi
Rollback pada saga pattern dengan cara event atau koreografi ini di jalankan dengan cara mempublish event yang tujuannya mengembalikan proses yang telah di lakukan oleh proses-proses sebelumnya. Sehingga proses rollback ini tidaklah terjadi secara gratis. Kita musti menuliskan code tambahan ketika rollback terjadi.
Sebagai contoh adalah ketika kita akan mengupdate data stock dan ternyata ketersedian stock sudah habis maka proses rollback yang terjadi dapat di jelaskan sebagai berikut.
- Stock Service mempublish event PRODUCT_OUT_OF_STOCK
- Kedua proses sebelumnya yaitu, Order dan Payment akan mendengar event PRODUCT_OUT_OF_STOCK dan melakukan proses:
- Refund atau mengembalikan dana client
- Status pada Order Service di tetapkan sebagai gagal.
Kelebihan dan Kekurangan Saga Pattern Pendekatan Event atau Koreografi
Event koreografi ini adalah pendekatan alami dalam mengimplementasikan saga pattern. Caranya sederhana dan mudah untuk di mengerti. Semua service yang terlibat dalam transaksi sangat terbebas satu sama lain. Jika transaksi kita cuma 2 atau sampai 5 tahap cara ini rasanya adalah cara yang paling cocok untuk digunakan.
Akan tetapi, jika transaksi kita tahapannya sudah banyak dan kemungkinan proses kedepanya untuk perubahan sangat besar maka proses transaksi yang kita punya akan sulit untuk kita monitor. Bahkan cara kita untuk melakukan test akan sangat sulit sekali, kita musti menjaga semua service jalan sehingga proses test bisa dijalan kan dengan baik.
Itulah penjelasan dari saga pattern dengan pendekatan event koreografi. Selanjutnya akan kita bahas jenis implementasi yang kedua yaitu command pattern atau orkestrasi pada artikel Saga Pattern dengan Command atau Orkestrasi.
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
