ardikabs / praktisi-mengajar-logbook

This is a logbook to track activity between the practitioner and the student
0 stars 0 forks source link

Saga Pattern #5

Closed hafisrabbani closed 1 day ago

hafisrabbani commented 5 days ago

Saya sedang belajar mengimplementasikan Saga Pattern untuk transaksi terdistribusi dalam aplikasi saya yang berbasis microservices. Sejauh ini saya menggunakan pendekatan Orchestration, di mana satu orchestrator bertanggung jawab mengatur langkah-langkah transaksi.

Namun, saya agak bingung tentang bagaimana pola komunikasi yang paling tepat antara layanan dalam context Saga. Apakah setiap langkah transaksi dalam Saga sebaiknya menggunakan pola Request-Reply (di mana orchestrator mengirimkan request ke setiap service dan menunggu balasan) atau lebih baik menggunakan mekanisme event-driven dengan publish-subscribe tanpa reply langsung?

Jika menggunakan Request-Reply, bagaimana cara terbaik menangani kompensasi jika terjadi kegagalan, terutama ketika ada service yang tidak merespon dengan benar atau terlambat? Bagaimana cara menghindari blocking orchestrator jika salah satu service lambat atau gagal merespon?

Selain itu, apakah ada skenario tertentu di mana menggunakan Request-Reply lebih menguntungkan dibandingkan event-driven dalam implementasi Saga Pattern?

ardikabs commented 5 days ago

@hafisrabbani

Apakah setiap langkah transaksi dalam Saga sebaiknya menggunakan pola Request-Reply (di mana orchestrator mengirimkan request ke setiap service dan menunggu balasan) atau lebih baik menggunakan mekanisme event-driven dengan publish-subscribe tanpa reply langsung?

Sejauh yang pernah saya handle, Saga pattern lebih sering dengan Event-Driven. Karena pendekatan Request-Reply ini menurut saya malah tightly coupled otomatis latency makin tinggi. Contohnya transaction failure, maka proses untuk nge revert semua step perlu diperhitungkan kembali. Lalu component orchestrator punya tanggung jawab berlebih menjaga reliabilitynya saat transaction failure tersebut, termasuk harus aware dengan order dari setiap langkah.

Jika menggunakan Request-Reply, bagaimana cara terbaik menangani kompensasi jika terjadi kegagalan, terutama ketika ada service yang tidak merespon dengan benar atau terlambat? Bagaimana cara menghindari blocking orchestrator jika salah satu service lambat atau gagal merespon?

IMO, orchestrator harusnya punya capability untuk melakukan tracking, sementara untuk blocking sebenernya ini tergantung bahasa pemrogramannya, tapi secara sederhananya concurrency sudah bisa menyelesaikan masalah terkait blocking. Lalu mekanisme semacam RetryPolicy dengan memerhatikan idempotency agar tiap langkah transaksi telah terjadi juga salah satu opsi untuk workaround intermittent failing.

Selain itu, apakah ada skenario tertentu di mana menggunakan Request-Reply lebih menguntungkan dibandingkan event-driven dalam implementasi Saga Pattern?

Ini jelas tergantung, kalau pendekatan pada sistem sudah sangat bergantung dengan API call maka Saga dengan Request-Reply akan jauh lebih mudah diterapkan. Karena underlying resourcenya sudah tersedia, dan jika berpindah ke Event-Driven dengan sistem tersebut maka cost yg diperlukan juga jadi besar. Tapi untuk long-term, arguably, menurut saya akan jauh lebih scale dan reliable dengan approach Event-Driven

hafisrabbani commented 1 day ago

baik mas ardika terimakasih banyak atas insightnya