Orchestration Saga — bir nechta service ishtirok etadigan uzun business transactionni markaziy orchestrator orqali qadamlar va compensating actionlarga ajratib boshqaradigan distributed transaction pattern. Har service o‘z local transactionini bajaradi. Bir qadam muvaffaqiyatsiz bo‘lsa oldingi qadamlarning ta’siri compensation orqali bekor qilinadi.
Pattern microservice arxitekturasida global ACID transaction o‘rniga eventual consistency bilan ishlaydi.
Saga
Saga bir nechta local transactionlar ketma-ketligi.
Masalan, order jarayoni:
Order yaratish
→ Inventory rezervi
→ Payment olish
→ Delivery yaratish
Har qadam boshqa service database’ida commit qilinishi mumkin.
Ularning barchasini bitta database transactionida rollback qilib bo‘lmaydi.
Orchestrator
Orchestrator saga holati va qadamlar tartibini boshqaradi.
U:
- keyingi commandni yuboradi;
- response yoki eventni kutadi;
- saga state’ni saqlaydi;
- timeoutni kuzatadi;
- failure’da compensation boshlaydi;
- yakuniy statusni belgilaydi.
Service’lar umumiy workflow’ni bilmasligi mumkin.
Command
Orchestrator service’ga bajarilishi kerak bo‘lgan amalni yuboradi.
Misollar:
ReserveInventory;ChargePayment;CreateShipment;CancelReservation;RefundPayment.
Command unique ID va saga IDga ega.
Reply yoki event
Service local transactiondan keyin natija qaytaradi.
Masalan:
InventoryReserved
InventoryRejected
PaymentCompleted
PaymentFailed
Orchestrator natijaga qarab keyingi state’ga o‘tadi.
Message duplicate va tartibsiz kelishi mumkin.
Compensation
Compensating action oldingi local transactionning business ta’sirini qaytaradi.
Masalan:
- rezervni bo‘shatish;
- paymentni refund qilish;
- deliveryni bekor qilish;
- bonusni qaytarib olish.
Compensation database rollback bilan bir xil emas.
U yangi business transaction hisoblanadi.
Qisman qaytarish
Har actionni aynan oldingi holatga qaytarib bo‘lmasligi mumkin.
Masalan, email yuborilgan bo‘lsa uni “yuborilmagan” qilish mumkin emas.
Compensation correction email yuborishi yoki statusni cancelled qilishi mumkin.
Shu sababli irreversible qadamlar saga oxiriga yaqin joylashtiriladi.
State machine
Orchestrator saga’ni state machine sifatida saqlaydi.
Misol:
STARTED
INVENTORY_RESERVED
PAYMENT_COMPLETED
SHIPMENT_CREATED
COMPLETED
COMPENSATING
FAILED
Har transition ruxsat etilgan eventlar bilan bog‘lanadi.
Unexpected event log qilinadi yoki deduplication qilinadi.
Persistent state
Orchestrator crash qilsa saga holati yo‘qolmasligi kerak.
State update va outgoing message uchun Transactional Outbox ishlatilishi mumkin.
Idempotency
Command qayta yetkazilishi mumkin.
Har participant command ID yoki business key bo‘yicha duplicate’ni aniqlaydi.
Masalan, ChargePayment bir saga uchun faqat bir marta haqiqiy charge yaratadi.
Compensation ham idempotent bo‘lishi kerak.
Timeout
Service javobi kelmasa orchestrator timeout eventini yaratadi.
ga olib kelishi mumkin.
Timeout operation bajarilmaganini isbotlamaydi; response yo‘qolgan bo‘lishi mumkin.
Retry
Transient failure’da command qayta yuboriladi.
Doimiy business rad etish retry qilinmaydi.
Pivot transaction
Saga ichidagi ayrim qadamdan keyin ortga qaytish qimmat yoki imkonsiz bo‘lishi mumkin.
Bu qadam pivot transaction deb qaraladi.
Undan oldingi qadamlar compensatable, keyingilari esa retryable bo‘lishi mumkin.
Workflow dizayni shu nuqtani hisobga oladi.
Orchestration va Choreography
Orchestration’da markaziy component workflow’ni boshqaradi.
Choreography’da service’lar eventlarga javob berib, markaziy boshqaruvchisiz davom etadi.
Orchestration:
- oqim aniq;
- monitoring osonroq;
- markaziy coupling mavjud.
Choreography:
Concurrency
Bir entity uchun ikki saga parallel boshlanishi mumkin.
Masalan, bir orderni bekor qilish va to‘lash bir vaqtda.
Optimistic version, lock yoki business state transition conflictni boshqaradi.
Orchestrator faqat o‘z saga state’ini emas, domain concurrency’ni ham hisobga oladi.
Observability
Har saga uchun timeline saqlanadi:
Distributed trace saga ID bilan bog‘lanadi.
Uzoq davom etayotgan saga alert beradi.
Manual intervention
Compensation ham muvaffaqiyatsiz bo‘lishi mumkin.
Masalan, refund provider uzoq vaqt ishlamaydi.
Saga MANUAL_REVIEW holatiga o‘tkaziladi.
Operatorga kerakli context va xavfsiz qayta urinish vositasi beriladi.
Command deduplication
Orchestrator ayni commandni retry qilganda yangi business operation emas, o‘sha commandning takrori bo‘lishi kerak.
Participant command_id uchun unique constraint saqlashi mumkin.
Oldingi natija mavjud bo‘lsa uni qaytaradi.
Versioned workflow
Saga davom etayotgan paytda yangi application release chiqishi mumkin.
Workflow definition o‘zgarsa eski saga qaysi qadamlar bilan davom etishi aniq bo‘lishi kerak.
Saga record workflow versionini saqlaydi yoki backward-compatible handlerlar ishlatiladi.
Compensation tartibi
Compensation odatda bajarilgan qadamlarning teskari tartibida yuradi.
Biroq dependency bo‘lmasa ayrim compensationlar parallel bajarilishi mumkin.
Parallelizm business invariant va tashqi provider limitiga mos bo‘ladi.
Saga data
Orchestrator barcha domain obyektlarini nusxalamasdan, workflow uchun kerakli minimal state’ni saqlaydi.
Katta payload object storage yoki participantlarda qoladi.
Saga state ichidagi personal data retention va audit qoidalariga bo‘ysunadi.
Deployment
Orchestrator instance’lari stateless worker sifatida ko‘paytirilishi mumkin, ammo saga record update’i optimistic version yoki lock bilan himoyalanadi.
Aynan bir event ikki worker tomonidan parallel qayta ishlanmasligi kerak.
Bog‘liq tushunchalar
Saga pattern, Orchestrator, Compensating transaction, Local transaction, State machine, Eventual consistency, Transactional Outbox, Choreography, Idempotency