Saga Game ? Lost of Saga ? Senior sekali anda !! atau daun Saga ?

– Serius dikit napah ..

Ok..ok.., ini bukan tentang game Saga, Lost of Saga, atau pun Saga-sagaan yang lain..

Apalagi tentang daun Saga 😁

Ini tentang mendesain alur dari interaksi banyak microservice.


Apa itu Saga Pattern ?

Saga pattern adalah salah satu Design Pattern untuk microservice.

Saga pattern ini biasanya digunakan untuk kasus Distribution Transaction Management

Saga pattern akan mengelola distributed transaction dengan cara memastikan transaksi-transaksi local dijalankan berurutan dan saling berkaitan.

Bingung nggak ? bingung nggak ? bingung laah, masak enggak !.


Apa maksudnya Distribution Transaction ?

Dalam bahasa sederhana, Distribution Transaction adalah sebuah proses yang terdiri dari banyak step/tahapan, yang masing-masing step/tahapan dijalankan di service yang berbeda, dan juga transaksi lokal yang berbeda pula.


Contohnya : Pada proses submission e-commerce. (di waktu klik tombol “Pesan/Order”)

Satu klik proses submission e-commerce diatas bisa terdiri dari banyak tahapan/step :

  • Submit Order.
  • Update status pembayaran.
  • Update stok barang.
  • Kirim data tentang delivery/pengiriman barang.
  • Kirim email konfirmasi atau informasi ke customer.

Semua rangkaian tahapan diatas dianggap sebuah transaksi, yang artinya semua tahapan diatas mesti berhasil atau gagal semuanya.

Apabila salah satu tahapan gagal, maka harus dibuat cara agar tahapan yang gagal tadi bisa diulang lagi, sehingga pada akhirnya secara keseluruhan transaksi dianggap berhasil.

Atau apabila salah satu tahapan gagal, maka harus ada cara untuk melakukan roll back untuk tahapan yang sudah berhasil sebelumnya, sehingga ujung-ujungnya transaksi diatas secara keseluruhan dianggap tidak terjadi/rolling back.

Atau apabila salah satu tahapan gagal, bisa juga dilakukan proses retryable untuk tahapan yang gagal tersebut, sehingga ujung-ujungnya transaksi diatas secara keseluruhan berhasil.

Disinilah Saga Pattern berfungsi.


Kenapa ini penting di arsitektur microservice ?

Hal diatas penting karena di arsitektur microservice, mau tak mau kita tetap harus menjaga konsep Transaction dalam sebuah proses yang memang mengharuskan seperti itu.

Dikutip dari wikipedia

Transaction processing is information processing in computer science[1] that is divided into individual, indivisible operations called transactions. Each transaction must succeed or fail as a complete unit; it can never be only partially complete.

Terjemahan bebas :

Transaction adalah pemrosesan informasi yang terdiri dari banyak tahapan yang secara keseluruhan dianggap sebagai sebuah kesatuan unit yang lengkap. Pemrosesan dianggap tidak lengkap kalau ada satu saja tahapan yang gagal. Berhasil semua atau gagal semua.

Artinya konsep Transaction ini berlaku secara umum, apakah kita menggunakan arsitektur microservice atau tidak.

Transaction bisa kita capai dengan mudah ketika menggunakan arsitektur Monolitik, yang biasanya hanya mempunyai satu database, satu server, satu proses di memory, atau dengan sedikit proses yang berada diluar kendali proses utama.

Dengan kata lain, untuk kasus arsitektur Monolitik, maka satu kali commit sudah cukup, karena databasenya sama, prosesnya di code yang sama, dll.

Tetapi dengan menggunakan microservice, hal diatas menjadi tantangan tersendiri.

Hal ini namanya masalah Distributed Transaction seperti yang kita sebutkan diatas.

Aplikasi sekarang menjadi terpisah-pisah servicenya, masing-masing service memiliki database masing-masing, server masing-masing, proses masing-masing.

Masing-masing tahapan di server yang terpisah ini akan mempunyai transaksi terpisah-pisah tersendiri.

Maka kompleksitas dalam sebuah transaksi menjadi lebih tinggi lagi. Kita bisa saja menjadi kehilangan informasi mengenai tahapan/step apa saja yang sudah berhasil/gagal dari sebuah proses transaksi.

Coba kita lihat lagi di submission e-commmerce

Kalau kita lihat, contoh transaksi e-commerce di atas melibatkan banyak microservices.

Coba kita lihat tahapan dan service yang terkait dengannya :

  • Submit Order. –> OrderService
  • Update status pembayaran. –> PaymentService
  • Update stok barang. –> StockService
  • Kirim data delivery. –> DeliveryService
  • Kirim email konfirmasi atau informasi ke customer. –> NotificationService.

Tiap-tiap service diatas merupakan server yang terpisah, mempunyai database terpisah, dan bisa saja memanggil service pihak ketiga.

Oleh karena itu perlu sebuah cara agar sebuah proses Distribution Transaction diatas bisa dikelola.

Saga Pattern menjadi salah satu caranya.

Jadi apa yang dilakukan oleh Saga Pattern ?

Saga Pattern melakukan pengelolaan transaksi terdistribusi itu melalui transaksi di tiap tahapan terpisah-pisah di masing-masing services. Kemudian tiap transaksi terpisah itu mengupdate statusnya dan dilanjutkan ke transaksi tahapan berikutnya, melalui coordinator/event/message/dll.

Ketika sebuah tahapan transaksi gagal, maka akan ada proses rollback atau retryable di tahapan yang terkait, sehingga secara keseluruhan tetap menjamin sempurnanya sebuah transaksi secara keseluruhan.

Bagaimana caranya ?

Saga Pattern didesain dengan cara membuat sebuah Saga Execution Manager/Coordinator sebagai pengelola dari tahapan/step yang dibutuhkan dari sebuah proses transaksi.

Baik nantinya memakai cara Orkestrasi ataupun Koreografi, Saga pattern tetap membutuhkan Manager/Coordinator di dalam menentukan seluruh proses transaksi berjalan sempurna, walaupun dalam porsi berbeda.

Mengenai Orkestrasi ataupun Koreografi, kita angkat di artikel selanjutnya.