Strategi Retry dan Rollback dalam Sistem Monolith dan Microservices

Dalam sebuah sistem backend yang baik, konsistensi data merupakan hal yang sangat diperlukan. Misal kita mempunyai api untuk melakukan order, yang dimana flow bisnis nya adalah membuat order dan melakukan pemotongan stock di product. Coba bayangkan apa jadinya jika data order berhasil dibuat, namun stock product tidak terpotong. Maka yang terjadi adalah inkonsistensi data, dan ini buruk karena sekarang data kita jadi tidak dapat dipercaya. Untuk lebih menggambarkan permasalah yang terjadi mari saya coba gambarkan :

Untuk menghindari hal tersebut, maka sistem backend kita harus mempunyai kemampuan untuk melakukan retry dan rollback agar data kita tetap konsisten. Agar lebih jelas mengenai retry dan rollback ini, mari saya coba jelaskan :

1. Retry

Merupakan upaya mengulangi proses yang sebelumnya gagal, biasanya dilakukan beberapa kali sampai proses berhasil dilakukan (biasanya api retry di aplikasi lain harus idempotency, agar data yang dibuat tidak duplikat jika proses retry berhasil). Namun jika tetap gagal dalam beberapa kali percobaan tersebut, maka akan dinyatakan sebagai proses yang gagal permanen.

Lalu bagaimana cara melakukan retry? yaitu dengan mencoba melakukan beberapa percobaan untuk melakukan proses yang sebelumnya gagal. Biasanya retry dilakukan setelah menunggu dalam jeda waktu tertentu, ini dilakukan untuk mengetahui apakah kegagalan diproses sebelumnya itu bersifat sementara ataukah tidak. Untuk melakukan retry ada beberapa strategi yang bisa dilakukan :

• Constant Retry

Melakukan retry dengan jeda waktu yang sama, misal setiap 5 detik sistem kita akan mencoba melakukan percobaan untuk melakukan retry. Kekurangan dari cara ini adalah akan membuat service yang sedang bermasalah menjadi kelebihan beban, karena terus menerus di kirimi proses retry dengan jeda waktu yang sama (thundering herd problem). Dan ini bisa memperburuk keadaan dari service yang sedang bermasalah tadi, bahkan service tersebut bisa mengalami kegagalan beruntun (cascading failure). Untuk lebih menggambarkan kondisinya mari saya coba gambarkan :

• Exponential Backoff

Melakukan retry dengan jeda waktu yang naik secara exponensial, misal retry pertama dilakukan di detik 1, retry kedua dilakukan di detik ke 3 dan seterusnya. Meskipun waktu retry cukup dinamis, namun cara ini tentu ada kelemahannya juga yaitu waktu tunggu untuk melakukan retry yang bisa terlalu lama, jika tidak ada batas maximum waktu jeda untuk melakukan retry nya. Dan sebenarnya cara ini masih memiliki permasalahan yang sama dengan cara constant retry, yaitu akan mengirim proses retry dalam waktu yang bersamaan. Untuk lebih menggambarkan kondisinya mari saya coba gambarkan :

• Jitter

Melakukan retry dengan exponential backoff namun ditambah dengan jitter ( variasi acak ), agar proses retry yang dilakukan tidak dalam waktu yang serentak. Sehingga tidak akan mengirim retry dalam waktu yang bersamaan (karena ada faktor dari jitter), sehingga service yang bermasalah akan memiliki waktu untuk segera pulih kembali tanpa harus mendapatkan kelebihan beban berlebih ketika proses retry berlangsung. Untuk lebih menggambarkan kondisinya mari saya coba gambarkan :

Jika ingin melihat contoh code untuk implementasi exponential backoff dengan jitter ini, saya sudah coba buatkan dalam bentuk library di bahasa ruby : exp_backoff.

Get Solehudin MQ’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

2. Rollback

Merupakan mekanisme untuk mengembalikan proses yang gagal ke keadaan semula. Sebagai contoh ketika kita melakukan order, maka data order akan dibuat dan stok produk akan dipotong. Namun ketika ada kegagalan di salah satu tempat saja, misal terjadi kegagalan ketika memotong stok produk maka kita harus melakukan rollback dengan cara menghapus data order yang sebelumnya sudah dibuat agar data kita tetap konsisten. Dan berikut merupakan beberapa cara yang bisa dilakukan untuk melakukan rollback, untuk contoh kasus ketika kita melakukan order :

• Rollback di Sistem Monolith

Untuk melakukan rollback di sistem monolith ini terhitung mudah, yaitu dengan menggunakan transaction. Ketika salah satu proses gagal ketika melakukan order, maka seluruh proses sebelumnya akan di batalkan. Untuk lebih jelasnya, mari saya coba contohkan dalam code di bahasa ruby :

ApplicationRecord.transaction do
 product = Product.lock.find_by!(id: product_id) # lock product   


 # 1. Membuat order baru
 order = Order.new(order_params)
 order.product = product
 order.save!


 # 2. Mengurangi stok produk
 # Pastikan stok mencukupi
 if product.stock > 0
   product.stock -= 1
   product.save!
 else
   # Jika stok tidak mencukupi, lempar exception
   # Ini akan memicu rollback dari seluruh transaksi
   raise "Stok produk tidak mencukupi."
 end
end

• Rollback di Sistem Microservices

Untuk melakukan rollback di sistem microservices, tentu ini akan lebih kompleks dibandingkan di sistem monolith. Kenapa ? karena bisa jadi ada flow bisnis yang mengharuskan kita untuk berkomunikasi dengan lebih dari 1 service. Artinya kegagalan di salah satu service saja, maka seluruh service yang terhubung dengan flow bisnis tersebut harus melakukan rollback. Kita coba ambil contoh kasus ketika membuat order, misal proses membuat order berhasil di order service namun gagal ketika memotong stok di product service. Setelah melakukan retry ternyata tetap gagal juga, akhirnya seluruh data harus di rollback. Lalu bagaimana caranya? berikut penjelasannya :

a. Rollback di Orchestrator Service

Karena jenis ini memiliki workflow terpusat, maka setiap service yang dipanggil secara berurut harus memiliki kemampuan untuk mengecek kegagalan dan melakukan retry. Jika dengan retry masih gagal, maka proses rollback harus dilakukan untuk membatalkan proses di service yang sebelumnya telah dipanggil. Untuk lebih jelasnya mari saya coba gambarkan :

b. Rollback di Choreography Service

Karena jenis ini memiliki workflow yang tidak terpusat, artinya setiap service akan bereaksi berdasarkan event yang mereka konsumsi saja (event driven). Lalu bagaimana cara melakukan rollback jika workflow nya tidak terpusat? yaitu dengan cara mengirimkan event kegagalan ketika proses retry gagal dilakukan, yang nantinya akan dikonsumsi oleh semua service yang terkait (dalam kasus ini adalah order service). Untuk lebih jelasnya mari saya coba gambarkan :

Nah teman-teman tadi itu merupakan penjelasan mengenai strategi retry dan rollback dalam sistem monolith dan microservices, mudah-mudahan bisa bermanfaat. Jika ada hal yang salah dari apa yang saya sampaikan, silahkan sampaikan di kolom komentar agar kita sama-sama belajar. Segitu saja dulu teman-teman tulisan saya kali ini, enjoy!