SlideShare a Scribd company logo
1 of 44
Microservice
Architecture
Saga Pattern
Koreografi dan Orkestrasi
Latar
Belakang
Struggle dan kesalahan
implementasi
1. Pertanyaan dari teman-teman
2. Masih melihat cara implementasi yang salah
3. Banyak sistem yang telah migrasi ke
microservice malah lebih banyak masalahnya
4. Banyak yang takut dan tidak tahu bagaimana
implementasi microservice yang benar
5. Menjaga konsistensi data pada microservice
Siapa Saya?
https://medium.com/the-legend
Saga Pattern on
Microservice
An Architectural Pattern for Manage a Transactional and Data
Consistency in Microservice
Data konsistensi mudah?
1. Konsistensi data adalah bagian terpenting dari
sebuah software.
2. Transactional cara untuk menjaga konsistensi data
(ACID).
3. Pada monolith menggunakan two phase commit
4. Local transaction dan global transaction.
5. Microservice tidak bisa dengan two phase commit.
Data konsistensi mudah?
ACID (Atomicity, Consistency, Durability, Isolation)
2 phase commit (2pc)
1. 2pc adalah protokol standar yang memastikan bahwa komit
database diimplementasikan dalam situasi di mana operasi komit
harus dipecah menjadi dua bagian terpisah.
2. Istilah pada 2pc
- Saving data = commit
- Undone data = rollback
1. Implementasi 2pc
- Tahap 1 - Setiap server atau database yang perlu melakukan
menulis data akan menulis datanya ke log. Jika server atau database
tidak berhasil, ia merespons dengan pesan kegagalan. Jika berhasil,
server atau database membalas dengan pesan OK.
2 phase commit (2pc)
Tahap 2 - tahap ini dimulai setelah semua peserta menjawab OK.
Kemudian, koordinator mengirimkan sinyal ke setiap server dengan
instruksi komit. Setelah melakukan, masing-masing menulis komit
sebagai bagian dari rekaman lognya untuk referensi dan
mengirimkan pesan kepada koordinator bahwa komitnya telah
berhasil diterapkan. Jika server gagal, koordinator mengirimkan
instruksi ke semua server untuk membatalkan transaksi. Setelah
server rollback, masing-masing mengirimkan feedback bahwa
proses telah diselesaikan.
1. Database harus support transaksional
2. Direct access pada database
3. Menggunakan driver yang support 2pc
4. Global transaksi membutuhkan aplikasi server seperti
Wildfly or WebLogic or Enduro/X in Go
Syarat 2 phase commit (2pc)
1. Karena tabel-tabel berada pada database yang
berbeda-beda dan satu tabel di manage hanya oleh
satu service maka konsep two phase commit tidak
bisa kita gunakan lagi
2. Global transaksi hanya bisa pada database lama dan
tidak cocok untuk microservice karena kemungkinan
terdapat latency yang tinggi dan menyalahi aturan satu
database di manage oleh satu jenis service,
2pc dan Global Transaksi
Ada minimal empat service yang terlibat dalam proses pemesanan.
Setiap service memiliki database sendiri-sendiri dan setiap data yang
terkait satu sama lain harus konsisten.
pemesanan akan mencari data dari tabel konsumen melalui service
konsumen dan pada saat yang sama, menulis datanya ke kitchen service
dan tabel akuntansi melalui service account.
Apa itu Saga Pattern?
1. Saga mengandung arti perjalanan saga pattern pertama kali
dipublikasi di tahun 1987 oleh Hector Garcia dan Molina and
Kenneth Salem.
2. Saga pattern digunakan pada long running transaksi yang
dapat dipecah ke dalam beberapa transaksi.
3. Saga pattern adalah arsitektural pattern yang dapat kita
gunakan untuk membangun sebuah microservice pattern
dan dikhususkan untuk menanggulangi masalah konsistensi
data.
4. Ada dua pendekatan saga pattern, event atau koreografi dan
command atau orkestrasi.
Saga adalah urutan transaksi lokal dimana setiap transaksi berjalan pada
sistem lokal masing-masing service. Transaksi pertama dimulai oleh
permintaan eksternal yang sesuai dengan pengoperasian sistem dan
kemudian setiap langkah berikutnya dipicu oleh penyelesaian proses
sebelumnya.
Event atau Koreografi
1. Pada saga dengan implementasi 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.
2. Saga pattern pada jenis ini akan berakhir jika service
terakhir yang terlibat melakukan transaksi lokal dan tidak
ada publish event apapun yang didengar oleh setiap
service yang terlibat pada saga.
1. Order Service menyimpan data order baru dan menentukan
state atau status pending dan sekaligus publish event dengan
nama, misalkan ORDER_CREATED.
2. Payment Service mendengarkan event ORDER_CREATED,
melakukan debet pada client, dan mempublish event
BILLED_ORDER. Pada proses ini triger bisa didatangkan juga dari
proses pembayaran yang dilakukan client.
3. Stock service mendengarkan event BILLED_ORDER, melakukan
update stok, melakukan persiapan untuk pengiriman produk
yang dibeli, dan mempublikasi event ORDER_PREPARED
4. Delivery Service mendengarkan event ORDER_PREPARED
melakukan pengambilan dan mengirimkan product. Apabila
telah selesai dia akan mempublish ORDER_DELIVERED.
5. Akhirnya, Order Service mendengar even ORDER_DELIVERED
dan menentukan state dari order telah beres dijalankan atau
dengan kata lain keseluruhan order FINISH.
Pada kasus di atas, apabila kita berkeinginan untuk melakukan
track dari semua proses yang terjadi, bisa dilakukan dengan
mudah yaitu Order Service akan mendengarkan semua event
dan melakukan update dari setiap state atau status yang terjadi.
Roll back Transaksi
Rollback pada saga pattern dengan cara event atau koreografi ini
dijalankan dengan cara mempublish event yang tujuannya
mengembalikan proses yang telah dilakukan oleh proses-proses
sebelumnya. Sehingga proses rollback ini tidaklah terjadi secara
gratis. Kita mesti menuliskan code tambahan ketika rollback
terjadi.
1. Stock Service mempublish event
PRODUCT_OUT_OF_STOCK
2. 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 ditetapkan sebagai
gagal.
Kelebihan dan Kekurangan
1. 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.
2. Jika transaksi kita tahapannya sudah banyak dan
kemungkinan proses development kedepan diperkirakan
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 mesti menjaga
semua service jalan sehingga proses tes bisa dijalankan
dengan baik.
Command atau Orkestrasi
Pada pendekatan orkestrasi kita memerlukan satu service
tambahan yang berperan sebagi pusat pengendali. Service
ini akan memberikan sejumlah intruksi atau perintah dan
berkomunikasi dengan semua service yang terlibat dalam
transaksi.
ORDER SAGA ORCHESTRATOR (OSO)
1. ORDER_SERVICE akan meminta OSO untuk memulai
menjalankan proses transaksi dan menyimpan status Order
sebagai Pending.
2. OSO akan mengirimkan perintah ke PAYMENT_SERVICE untuk
menjalankan proses pembayaran. Service ini akan memberikan
reply balik berupa proses berhasil ataupun gagal melalui saga
reply chanel.
3. Apabila PAYMENT_SERVICE memberikan pesan bahwa
payment telah tereksekusi maka OSO akan memberikan
perintah ke STOCK_SERVICE untuk melakukan persiapan
pengiriman barang.
4. STOCK_SERVICE akan memberikan pesan bahwa proses bisa di
lanjutkan karena stock tersedia dan OSO menerimanya sebagai
ORDER_PREPARED
5. OSO akan memberikan peritah ke DELIVERY_SERVICE untuk
melakukan pengiriman dan jika suskes akan memberikan
pesan ke OSO bahwa ORDER_DELIVERED.
6. OSO akan menyimpan status Order Finish.
Rollback Orkestrasi
Pada pendekatan orkestrasi ini proses rollback juga mudah untuk dilakukan.
Setiap service tinggal memberikan pesan ke command center dan OSO akan
menentukan proses selanjutnya.
1. Stock Service mempublish event ke channel replay
Chanel dengan pesan PRODUCT_OUT_OF_STOCK
2. OSO akan mendengar event PRODUCT_OUT_OF_STOCK
dan melakukan proses rollback.
● OSO mengirimkan pesan Refund ke PAYMENT_SERVICE
● PAYMENT_SERVICE mengembalikan dana customer.
● Status pada Order Service ditetapkan sebagai gagal.
Kelebihan dan Kekurangan
Kelebihan
1. Meniadakan ketergantungan antar service.
2. Distribusi transaksi terpusat.
3. Mudah untuk diimplementasikan dan di test.
4. Tingkat kesusahan dari transaksi bersifat linear.
5. Proses rollback mudah untuk ditangani.
6. Jika terdapat penambahan atau pengurangan proses
dan service yang terlibat sangat mudah untuk
dilakukan.
Kekurangan
1. Secara infrastruktur semakin banyak dan semakin
sulit karena harus memanage service tambahan
2. Hati-hati jika terjadi konsentrasi banyak sekali logika
yang terpusat di OSO.
3. OSO harus di jaga dan diyakinkan tingkat
avaibilitynya.
Tips Saga Pattern
Unik Id Setiap Transaksi Replay Chanel
Reply chanel cukup satu (nama
proses dan message)
Idempotent Proses Asynchronous Prosess
Ideal process, cost
efficient and effective
01
03 04
02
Referensi
1. https://medium.com/the-legend/saga-pattern-dengan-
command-atau-orkestrasi-2b0b76d966b6
2. https://medium.com/the-legend/saga-pattern-f46c989dc452
3. First Saga Pattern
4. https://medium.com/the-legend/system-design-trd-cheatsheet-
aff03e823afc
5. https://en.wikipedia.org/wiki/ACID
6. https://docs.oracle.com/cd/E18050_01/tuxedo/docs11gr1/pcb/p
bglob.html
—Deni Husni FR
“Keep in mind that API not only
runs from server to server but also
from people to people.”
Alternative Resources
https://medium.com/the-legend
CREDITS: This presentation template was created by Slidesgo, including
icons by Flaticon, infographics & images by Freepik and illustrations by
Stories
Thanks!
Do you have any questions?
dhfr123@gmail.com
+62 82117419014
https://medium.com/the-legend
https://www.linkedin.com/in/deni-husni-fahri-rizal-76954235/

More Related Content

What's hot

Zero-Copy Event-Driven Servers with Netty
Zero-Copy Event-Driven Servers with NettyZero-Copy Event-Driven Servers with Netty
Zero-Copy Event-Driven Servers with NettyDaniel Bimschas
 
Coroutines in Kotlin
Coroutines in KotlinCoroutines in Kotlin
Coroutines in KotlinAlexey Soshin
 
Pipeline oriented programming
Pipeline oriented programmingPipeline oriented programming
Pipeline oriented programmingScott Wlaschin
 
[수정본] 우아한 객체지향
[수정본] 우아한 객체지향[수정본] 우아한 객체지향
[수정본] 우아한 객체지향Young-Ho Cho
 
ColdFusion for Penetration Testers
ColdFusion for Penetration TestersColdFusion for Penetration Testers
ColdFusion for Penetration TestersChris Gates
 
Clean architecture with ddd layering in php
Clean architecture with ddd layering in phpClean architecture with ddd layering in php
Clean architecture with ddd layering in phpLeonardo Proietti
 
C++20 Key Features Summary
C++20 Key Features SummaryC++20 Key Features Summary
C++20 Key Features SummaryChris Ohk
 
Toi uu hoa he thong 30 trieu nguoi dung
Toi uu hoa he thong 30 trieu nguoi dungToi uu hoa he thong 30 trieu nguoi dung
Toi uu hoa he thong 30 trieu nguoi dungIT Expert Club
 
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023Steve Pember
 
Lecture 12: React-Native Firebase Authentication
Lecture 12: React-Native Firebase AuthenticationLecture 12: React-Native Firebase Authentication
Lecture 12: React-Native Firebase AuthenticationKobkrit Viriyayudhakorn
 
A philosophy of software design
A philosophy of software designA philosophy of software design
A philosophy of software designDiego Pacheco
 
High Concurrency Architecture at TIKI
High Concurrency Architecture at TIKIHigh Concurrency Architecture at TIKI
High Concurrency Architecture at TIKINghia Minh
 
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...Monica Beckwith
 
Go micro framework to build microservices
Go micro framework to build microservicesGo micro framework to build microservices
Go micro framework to build microservicesTechMaster Vietnam
 
PWA 與 Service Worker
PWA 與 Service WorkerPWA 與 Service Worker
PWA 與 Service WorkerAnna Su
 

What's hot (20)

JMeter
JMeterJMeter
JMeter
 
Zero-Copy Event-Driven Servers with Netty
Zero-Copy Event-Driven Servers with NettyZero-Copy Event-Driven Servers with Netty
Zero-Copy Event-Driven Servers with Netty
 
Coroutines in Kotlin
Coroutines in KotlinCoroutines in Kotlin
Coroutines in Kotlin
 
Learning Svelte
Learning SvelteLearning Svelte
Learning Svelte
 
Pipeline oriented programming
Pipeline oriented programmingPipeline oriented programming
Pipeline oriented programming
 
[수정본] 우아한 객체지향
[수정본] 우아한 객체지향[수정본] 우아한 객체지향
[수정본] 우아한 객체지향
 
ColdFusion for Penetration Testers
ColdFusion for Penetration TestersColdFusion for Penetration Testers
ColdFusion for Penetration Testers
 
Clean architecture with ddd layering in php
Clean architecture with ddd layering in phpClean architecture with ddd layering in php
Clean architecture with ddd layering in php
 
C++20 Key Features Summary
C++20 Key Features SummaryC++20 Key Features Summary
C++20 Key Features Summary
 
Toi uu hoa he thong 30 trieu nguoi dung
Toi uu hoa he thong 30 trieu nguoi dungToi uu hoa he thong 30 trieu nguoi dung
Toi uu hoa he thong 30 trieu nguoi dung
 
Performance testing locust
Performance testing   locustPerformance testing   locust
Performance testing locust
 
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023
 
Lecture 12: React-Native Firebase Authentication
Lecture 12: React-Native Firebase AuthenticationLecture 12: React-Native Firebase Authentication
Lecture 12: React-Native Firebase Authentication
 
A philosophy of software design
A philosophy of software designA philosophy of software design
A philosophy of software design
 
High Concurrency Architecture at TIKI
High Concurrency Architecture at TIKIHigh Concurrency Architecture at TIKI
High Concurrency Architecture at TIKI
 
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
 
Svelte
SvelteSvelte
Svelte
 
Mediator pattern
Mediator patternMediator pattern
Mediator pattern
 
Go micro framework to build microservices
Go micro framework to build microservicesGo micro framework to build microservices
Go micro framework to build microservices
 
PWA 與 Service Worker
PWA 與 Service WorkerPWA 與 Service Worker
PWA 與 Service Worker
 

Similar to Saga Pattern untuk Mengelola Konsistensi Data pada Microservice

Analisis permasalahan salinan data berganda
Analisis permasalahan salinan data bergandaAnalisis permasalahan salinan data berganda
Analisis permasalahan salinan data bergandaImmank Go
 
Zulyanti Megasari - Konkurensi
Zulyanti Megasari - KonkurensiZulyanti Megasari - Konkurensi
Zulyanti Megasari - Konkurensibelajarkomputer
 
Aplikasi jual beli online
Aplikasi jual beli onlineAplikasi jual beli online
Aplikasi jual beli onlineHendra Fillan
 
Proposal manajemen logistik 2018
Proposal manajemen logistik  2018Proposal manajemen logistik  2018
Proposal manajemen logistik 2018yoli lanar
 
Makalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdf
Makalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdfMakalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdf
Makalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdfElmitiodatacp
 
Ferli Apriadi - Konkurensi
Ferli Apriadi - KonkurensiFerli Apriadi - Konkurensi
Ferli Apriadi - Konkurensibelajarkomputer
 
Rbj 3.15 description tingkat perusahaan
Rbj 3.15 description tingkat perusahaanRbj 3.15 description tingkat perusahaan
Rbj 3.15 description tingkat perusahaanAli Must Can
 
02. proses pada so
02. proses pada so02. proses pada so
02. proses pada sokimerfan
 
PostgreSQL Transaksi
PostgreSQL TransaksiPostgreSQL Transaksi
PostgreSQL TransaksiAmmar Shadiq
 
Tugas spk loundry aplikasi sia 7
Tugas spk loundry aplikasi  sia 7Tugas spk loundry aplikasi  sia 7
Tugas spk loundry aplikasi sia 7Mardi Malow
 
Project charter trackit
Project charter trackitProject charter trackit
Project charter trackitCahya Adhi
 
Pertemuan ke 2
Pertemuan ke 2Pertemuan ke 2
Pertemuan ke 2ndriehs
 
Project charter trackit rev 1
Project charter trackit rev 1Project charter trackit rev 1
Project charter trackit rev 1Cahya Adhi
 
Slide3 manajemen proses
Slide3 manajemen prosesSlide3 manajemen proses
Slide3 manajemen prosesHz Tena
 

Similar to Saga Pattern untuk Mengelola Konsistensi Data pada Microservice (20)

Analisis permasalahan salinan data berganda
Analisis permasalahan salinan data bergandaAnalisis permasalahan salinan data berganda
Analisis permasalahan salinan data berganda
 
Transaction.pptx
Transaction.pptxTransaction.pptx
Transaction.pptx
 
Zulyanti Megasari - Konkurensi
Zulyanti Megasari - KonkurensiZulyanti Megasari - Konkurensi
Zulyanti Megasari - Konkurensi
 
Aplikasi jual beli online
Aplikasi jual beli onlineAplikasi jual beli online
Aplikasi jual beli online
 
Proposal manajemen logistik 2018
Proposal manajemen logistik  2018Proposal manajemen logistik  2018
Proposal manajemen logistik 2018
 
Uts mppl (1)
Uts mppl (1)Uts mppl (1)
Uts mppl (1)
 
Makalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdf
Makalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdfMakalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdf
Makalah Sistem operasi_UAS_Elmi Tiodata_210403010022.pdf
 
Oracle transaksi
Oracle transaksiOracle transaksi
Oracle transaksi
 
Ferli Apriadi - Konkurensi
Ferli Apriadi - KonkurensiFerli Apriadi - Konkurensi
Ferli Apriadi - Konkurensi
 
Rbj 3.15 description tingkat perusahaan
Rbj 3.15 description tingkat perusahaanRbj 3.15 description tingkat perusahaan
Rbj 3.15 description tingkat perusahaan
 
Transaction
TransactionTransaction
Transaction
 
02. proses pada so
02. proses pada so02. proses pada so
02. proses pada so
 
PostgreSQL Transaksi
PostgreSQL TransaksiPostgreSQL Transaksi
PostgreSQL Transaksi
 
Os ppt.6
Os ppt.6Os ppt.6
Os ppt.6
 
Pert.5 sinkronisasi dan deadlock
Pert.5 sinkronisasi dan deadlockPert.5 sinkronisasi dan deadlock
Pert.5 sinkronisasi dan deadlock
 
Tugas spk loundry aplikasi sia 7
Tugas spk loundry aplikasi  sia 7Tugas spk loundry aplikasi  sia 7
Tugas spk loundry aplikasi sia 7
 
Project charter trackit
Project charter trackitProject charter trackit
Project charter trackit
 
Pertemuan ke 2
Pertemuan ke 2Pertemuan ke 2
Pertemuan ke 2
 
Project charter trackit rev 1
Project charter trackit rev 1Project charter trackit rev 1
Project charter trackit rev 1
 
Slide3 manajemen proses
Slide3 manajemen prosesSlide3 manajemen proses
Slide3 manajemen proses
 

Saga Pattern untuk Mengelola Konsistensi Data pada Microservice

  • 2. Latar Belakang Struggle dan kesalahan implementasi 1. Pertanyaan dari teman-teman 2. Masih melihat cara implementasi yang salah 3. Banyak sistem yang telah migrasi ke microservice malah lebih banyak masalahnya 4. Banyak yang takut dan tidak tahu bagaimana implementasi microservice yang benar 5. Menjaga konsistensi data pada microservice
  • 4. Saga Pattern on Microservice An Architectural Pattern for Manage a Transactional and Data Consistency in Microservice
  • 5. Data konsistensi mudah? 1. Konsistensi data adalah bagian terpenting dari sebuah software. 2. Transactional cara untuk menjaga konsistensi data (ACID). 3. Pada monolith menggunakan two phase commit 4. Local transaction dan global transaction. 5. Microservice tidak bisa dengan two phase commit.
  • 6. Data konsistensi mudah? ACID (Atomicity, Consistency, Durability, Isolation)
  • 7. 2 phase commit (2pc) 1. 2pc adalah protokol standar yang memastikan bahwa komit database diimplementasikan dalam situasi di mana operasi komit harus dipecah menjadi dua bagian terpisah. 2. Istilah pada 2pc - Saving data = commit - Undone data = rollback 1. Implementasi 2pc - Tahap 1 - Setiap server atau database yang perlu melakukan menulis data akan menulis datanya ke log. Jika server atau database tidak berhasil, ia merespons dengan pesan kegagalan. Jika berhasil, server atau database membalas dengan pesan OK.
  • 8. 2 phase commit (2pc) Tahap 2 - tahap ini dimulai setelah semua peserta menjawab OK. Kemudian, koordinator mengirimkan sinyal ke setiap server dengan instruksi komit. Setelah melakukan, masing-masing menulis komit sebagai bagian dari rekaman lognya untuk referensi dan mengirimkan pesan kepada koordinator bahwa komitnya telah berhasil diterapkan. Jika server gagal, koordinator mengirimkan instruksi ke semua server untuk membatalkan transaksi. Setelah server rollback, masing-masing mengirimkan feedback bahwa proses telah diselesaikan.
  • 9. 1. Database harus support transaksional 2. Direct access pada database 3. Menggunakan driver yang support 2pc 4. Global transaksi membutuhkan aplikasi server seperti Wildfly or WebLogic or Enduro/X in Go Syarat 2 phase commit (2pc)
  • 10. 1. Karena tabel-tabel berada pada database yang berbeda-beda dan satu tabel di manage hanya oleh satu service maka konsep two phase commit tidak bisa kita gunakan lagi 2. Global transaksi hanya bisa pada database lama dan tidak cocok untuk microservice karena kemungkinan terdapat latency yang tinggi dan menyalahi aturan satu database di manage oleh satu jenis service, 2pc dan Global Transaksi
  • 11. Ada minimal empat service yang terlibat dalam proses pemesanan. Setiap service memiliki database sendiri-sendiri dan setiap data yang terkait satu sama lain harus konsisten.
  • 12. pemesanan akan mencari data dari tabel konsumen melalui service konsumen dan pada saat yang sama, menulis datanya ke kitchen service dan tabel akuntansi melalui service account.
  • 13. Apa itu Saga Pattern?
  • 14. 1. Saga mengandung arti perjalanan saga pattern pertama kali dipublikasi di tahun 1987 oleh Hector Garcia dan Molina and Kenneth Salem. 2. Saga pattern digunakan pada long running transaksi yang dapat dipecah ke dalam beberapa transaksi. 3. Saga pattern adalah arsitektural pattern yang dapat kita gunakan untuk membangun sebuah microservice pattern dan dikhususkan untuk menanggulangi masalah konsistensi data. 4. Ada dua pendekatan saga pattern, event atau koreografi dan command atau orkestrasi.
  • 15. Saga adalah urutan transaksi lokal dimana setiap transaksi berjalan pada sistem lokal masing-masing service. Transaksi pertama dimulai oleh permintaan eksternal yang sesuai dengan pengoperasian sistem dan kemudian setiap langkah berikutnya dipicu oleh penyelesaian proses sebelumnya.
  • 17. 1. Pada saga dengan implementasi 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. 2. Saga pattern pada jenis ini akan berakhir jika service terakhir yang terlibat melakukan transaksi lokal dan tidak ada publish event apapun yang didengar oleh setiap service yang terlibat pada saga.
  • 18.
  • 19. 1. Order Service menyimpan data order baru dan menentukan state atau status pending dan sekaligus publish event dengan nama, misalkan ORDER_CREATED. 2. Payment Service mendengarkan event ORDER_CREATED, melakukan debet pada client, dan mempublish event BILLED_ORDER. Pada proses ini triger bisa didatangkan juga dari proses pembayaran yang dilakukan client. 3. Stock service mendengarkan event BILLED_ORDER, melakukan update stok, melakukan persiapan untuk pengiriman produk yang dibeli, dan mempublikasi event ORDER_PREPARED
  • 20. 4. Delivery Service mendengarkan event ORDER_PREPARED melakukan pengambilan dan mengirimkan product. Apabila telah selesai dia akan mempublish ORDER_DELIVERED. 5. Akhirnya, Order Service mendengar even ORDER_DELIVERED dan menentukan state dari order telah beres dijalankan atau dengan kata lain keseluruhan order FINISH.
  • 21. Pada kasus di atas, apabila kita berkeinginan untuk melakukan track dari semua proses yang terjadi, bisa dilakukan dengan mudah yaitu Order Service akan mendengarkan semua event dan melakukan update dari setiap state atau status yang terjadi.
  • 23. Rollback pada saga pattern dengan cara event atau koreografi ini dijalankan dengan cara mempublish event yang tujuannya mengembalikan proses yang telah dilakukan oleh proses-proses sebelumnya. Sehingga proses rollback ini tidaklah terjadi secara gratis. Kita mesti menuliskan code tambahan ketika rollback terjadi.
  • 24. 1. Stock Service mempublish event PRODUCT_OUT_OF_STOCK 2. 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 ditetapkan sebagai gagal.
  • 26. 1. 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.
  • 27. 2. Jika transaksi kita tahapannya sudah banyak dan kemungkinan proses development kedepan diperkirakan 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 mesti menjaga semua service jalan sehingga proses tes bisa dijalankan dengan baik.
  • 29. Pada pendekatan orkestrasi kita memerlukan satu service tambahan yang berperan sebagi pusat pengendali. Service ini akan memberikan sejumlah intruksi atau perintah dan berkomunikasi dengan semua service yang terlibat dalam transaksi.
  • 31.
  • 32. 1. ORDER_SERVICE akan meminta OSO untuk memulai menjalankan proses transaksi dan menyimpan status Order sebagai Pending. 2. OSO akan mengirimkan perintah ke PAYMENT_SERVICE untuk menjalankan proses pembayaran. Service ini akan memberikan reply balik berupa proses berhasil ataupun gagal melalui saga reply chanel. 3. Apabila PAYMENT_SERVICE memberikan pesan bahwa payment telah tereksekusi maka OSO akan memberikan perintah ke STOCK_SERVICE untuk melakukan persiapan pengiriman barang.
  • 33. 4. STOCK_SERVICE akan memberikan pesan bahwa proses bisa di lanjutkan karena stock tersedia dan OSO menerimanya sebagai ORDER_PREPARED 5. OSO akan memberikan peritah ke DELIVERY_SERVICE untuk melakukan pengiriman dan jika suskes akan memberikan pesan ke OSO bahwa ORDER_DELIVERED. 6. OSO akan menyimpan status Order Finish.
  • 35. Pada pendekatan orkestrasi ini proses rollback juga mudah untuk dilakukan. Setiap service tinggal memberikan pesan ke command center dan OSO akan menentukan proses selanjutnya.
  • 36. 1. Stock Service mempublish event ke channel replay Chanel dengan pesan PRODUCT_OUT_OF_STOCK 2. OSO akan mendengar event PRODUCT_OUT_OF_STOCK dan melakukan proses rollback. ● OSO mengirimkan pesan Refund ke PAYMENT_SERVICE ● PAYMENT_SERVICE mengembalikan dana customer. ● Status pada Order Service ditetapkan sebagai gagal.
  • 38. Kelebihan 1. Meniadakan ketergantungan antar service. 2. Distribusi transaksi terpusat. 3. Mudah untuk diimplementasikan dan di test. 4. Tingkat kesusahan dari transaksi bersifat linear. 5. Proses rollback mudah untuk ditangani. 6. Jika terdapat penambahan atau pengurangan proses dan service yang terlibat sangat mudah untuk dilakukan.
  • 39. Kekurangan 1. Secara infrastruktur semakin banyak dan semakin sulit karena harus memanage service tambahan 2. Hati-hati jika terjadi konsentrasi banyak sekali logika yang terpusat di OSO. 3. OSO harus di jaga dan diyakinkan tingkat avaibilitynya.
  • 40. Tips Saga Pattern Unik Id Setiap Transaksi Replay Chanel Reply chanel cukup satu (nama proses dan message) Idempotent Proses Asynchronous Prosess Ideal process, cost efficient and effective 01 03 04 02
  • 41. Referensi 1. https://medium.com/the-legend/saga-pattern-dengan- command-atau-orkestrasi-2b0b76d966b6 2. https://medium.com/the-legend/saga-pattern-f46c989dc452 3. First Saga Pattern 4. https://medium.com/the-legend/system-design-trd-cheatsheet- aff03e823afc 5. https://en.wikipedia.org/wiki/ACID 6. https://docs.oracle.com/cd/E18050_01/tuxedo/docs11gr1/pcb/p bglob.html
  • 42. —Deni Husni FR “Keep in mind that API not only runs from server to server but also from people to people.”
  • 44. CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, infographics & images by Freepik and illustrations by Stories Thanks! Do you have any questions? dhfr123@gmail.com +62 82117419014 https://medium.com/the-legend https://www.linkedin.com/in/deni-husni-fahri-rizal-76954235/