Сағаттар және бөлінген транзакциялар

Сага - бұл әртүрлі сервистерде/қоймаларда жергілікті қадамдардың бірізділігіне бөлінген ұзақ мерзімді бизнес-транзакция. Әрбiр қадамның iшiнара сәтсiздiк кезiнде қадамның әсерiн қайтаратын өтемдiк әрекетi болады. 2PC/3PC қарағанда, сағалар жаһандық бұғаттауларды ұстап тұрмайды және eventual consistency рұқсат етілген микросервистерге, көп өңірлерге және жоғары жүктемелерге жарамды.

1) Сағаларды қашан таңдау керек (ал қашан - жоқ)

• Ұзақ/көп сатылы бизнес-процестер (тапсырыс → төлем → резерв → жеткізу).
• Ортақ транзакция жоқ әртүрлі домендер мен қоймалар.
• Жоғары қолжетімділік пен көлденең масштабтау қажет.

• Қатты ACID-атомарлық сыни (мысалы, бір тізілім шегінде үлкен сомаларды көшіру).
• Нақты өтелімділік жоқ («бір рет сақтау» немесе әсерді жою мүмкін емес).
• Заңдық/реттеушілік шектеулер қатаң оқшаулауды және «жедел» инвариантты талап етеді.

2) Сағалардың үлгілері

1. Оркестрлеу (Saga Orchestrator): орталық үйлестіруші қадамдар мен өтемақыларды басқарады.

Артықшылықтары: айқын ағын, қателерді бақылау, оңайлатылған телеметрия.
Кемшіліктері: орталықтандыру нүктесі, «қалың» үйлестірушінің тәуекелі.

2. Хореография (Choreography): орталық жоқ - қадамдар оқиғаларға байланысты («Сервисті жасаған X → сервис Б әрекет етеді»).

Артықшылықтары: әлсіз байланыстылық, қарапайым масштабтау.
Минустар: ағынды қадағалау/тежеу қиынырақ, ережелердің «өсу» қаупі.

3. TCC (Try-Confirm/Cancel): әрбір қадам - «резервтеу» (Try), содан кейін растау (Confirm) немесе болдырмау (Cancel).

Артықшылықтары: жалған-екі фазалық хаттамаға жақын, басқарылатын ресурстар.
Минустар: интерфейстерді іске асыруда қымбат; «Try» ұстаушыларының таймауттарын талап етеді.

3) Қадамды және өтемақыны жобалау

Инварианттар: қадамға дейін/кейін (мысалы, «қалдық ≥ 0») нені нақты тұжырымдаңыз.
Өтемақы ≠ кері транзакция: бұл бизнес-әсерді жоятын логикалық әрекет (refund, release, restore).
Теңсіздік: қадам да, компенсатор да қауіпсіз қайталануы тиіс ('operation _ id' бойынша).
Таймауттар: әрбір қадамда deadline бар; кешіктіру өтемақыға бастамашылық жасайды.
Қайтарымсыз әсерлер: оларды бөлек белгілеңіз (хабарламалар, e-mail) және «best effort» рұқсат етіңіз.

4) Келісімділік және тәртіп

Eventual consistency: пайдаланушылар уақытша айырмашылықтарды көре алады; UX - «күту «/спиннерлер/мәртебелерімен.
Кілт бойынша тәртібі: коммутациялық қадамдарды бизнес кілті бойынша топтастырыңыз (оқиғаларды реттеу үшін order_id).
Дедупликация: TTL бар өңдеу журналын ('operation _ id' → мәртебесі) сақтаңыз.

5) Көлік және сенімділік

Outbox pattern: оқиғаны сол транзакцияның ішінде жергілікті «outbox» кестесіне жазу, содан кейін шинаға асинхрондық жариялау.
Inbox/Idempotency store: тұтынушы жағында - өңделген хабарлар журналы.
Exactly-once тиімді: «outbox + idempotent consumer» практикалық «тура бір рет» береді.
DLQ: бай мета-ақпараты және қауіпсіз редрайві бар «улы» хабарламалар үшін.

6) Қателер саясаты, ретра, backoff

Біз тек идемпотенттік қадамдарды қайталаймыз; жазу операциялары - 'Idempotency-Key'.
Экспоненциалды backoff + джиттер; саганың талпыныстары мен жиынтық мерзімін шектеу.
Жүйелік тозу кезінде - Circuit Breaker және graceful degradation (мысалы, саганың екінші фич-бөлігін алып тастау).
Бизнес-қақтығыстар ('409') - келісуден кейін қайталау немесе орнын толтыру және аяқтау.

7) Оркестратор: міндеттері мен құрылымы

• Саганың күйін бақылау: 'PENDING → RUNNING → COMPENSATING → DONE/FAILED'.
• Қадамдарды, мерзімдерді, таймауттарды, ретраларды жоспарлау.
• Оқиғаларды роутингтеу және өтемақыны іске қосу.
• Үйлестіруші операцияларының ұқсастығы (командалар журналы).
• Бақылау мүмкіндігі: 'saga _ id' өрнегі логтарда/трестерде/метриктерде.

• 'saga', 'saga _ step', 'commands', 'outbox' кестелері.
• «saga _ id», «business _ key», «status», «next _ run _ at» бойынша индекстер.

8) Хореография: ереже және «қарлы комадан» қорғау

Оқиғалар келісімшарттары: схемалар және нұсқалау (Euro/Proto/JSON Schema).
Нақты семантика: "факт оқиғасы" vs "командасы.
Тізбекті тоқтату: сәйкессіздікті анықтаған сервис 'Failed '/' Compensate' оқиғасын жариялайды.
Шексіз ілмектерге арналған сигнализация мен алерталар.

9) TCC: практикалық бөлшектер

Try: TTL ресурсының қоры.
Confirm: уақытша бұғаттауды бекіту, босату.
Cancel: резервті қайтару (жанама әсерлерсіз).
Garbage collection: TTL-ден кейін Try автоматты түрде бас тарту.
Теңшелетін Confirm/Cancel: қайталау қауіпсіз.

10) Мысал (сөздік схема) - «Ақы төлеп және жеткізіп беру тапсырысы»

1. CreateOrder (жергілікті) → outbox: 'OrderCreated'.
2. PaymentService: 'Try' (TCC) резерві; табылған кезде → 'PaymentReserved', бас тартқан кезде → 'PaymentFailed'.
3. InventoryService: тауардың резерві; → 'InventoryFailed' жетіспеген жағдайда.
4. ShippingService: жеткізу слотын жасау (болдырмау).
5. Егер кез келген қадам 'Failed' болса → оркестратор өтемақыны кері ретпен іске қосады: 'CancelShipping' → 'ReleaseInventory' → 'PaymentCancel'.
6. Егер бәрі дұрыс болса → 'PaymentConfirm' → 'OrderConfirmed'.

11) Оркестрдің жалған құжаты

pseudo startSaga(saga_id, order_id):
steps = [ReservePayment, ReserveInventory, BookShipment, ConfirmPayment]
for step in steps:
res = execWithRetry(step, order_id)
if!res.ok:
compensateInReverse(steps_done(order_id))
return FAIL return OK

execWithRetry(step, key):
for attempt in 1..MAX:
try:
return step.run(key)    # идемпотентно catch RetryableError:
sleep(backoff(attempt))
catch NonRetryableError:
return FAIL return FAIL

compensateInReverse(done_steps):
for step in reverse(done_steps):
step.compensate()       # идемпотентно

12) Бақылау және операциялық SLO

Трейсинг: бірыңғай 'saga _ id', 'step', 'attempt', 'decision' аңдатпалары (run/compensate/skip).

• Сәттілік/сагдағы қате (%), орташа ұзақтығы, p95/p99.
• Өтемақы төлеу себептерінің тобы Өтемақы төлеу себептерінің үлесі
• Кезектер/outbox лагтар, қадамдар бойынша ретрайлер.
• Логи/аудит: оркестрдің шешімдері, ресурстардың сәйкестендіргіштері, бизнес-кілттер.

13) Тестілеу және хаос

Әрбір қадамға қателерді енгізу: таймауттар, '5xx', бизнес-қақтығыстар.
Out-of-order оқиғалар, көшірмелер, рұқсатнамалар (drop).
Латенттіліктің ұзын қалдықтары → мерзімдер мен өтемақыларды тексеру.
Жаппай сағалар → тексеру WFQ/DRR және caps кезектерде, жоқ «head-of-line blocking».
DLQ-дан адым бойынша және тұтас сағада редрайв.

14) Мульти-теңгерімділік, өңірлер,

'tenant _ id/plan/region' оқиғаларындағы және саг қоймаларындағы тегтер.
Residency: деректер/оқиғалар аймақтан шықпайды; кросс-өңірлік сағаларды жергілікті сағалар + біріктіруші оқиғалар федерациясы ретінде жобалаңыз.
Басымдылығы: VIP-сағалардың үлкен квоталық салмағы бар; per tenant воркерлерін оқшаулау.

15) Азық-түлік алдындағы чек-парағы

• Әрбір қадамның нақты компенсаторы бар, екеуі де - іспеттес.
• Үлгі таңдалды: оркестрлеу/хореография/ТСС; жауапкершілік шекаралары сипатталған.
• Outbox/Inbox ендірілген, 'operation _ id' бойынша дедупликация.
• Ретра саясаты: джиттермен backoff, талпыныс лимиттері және жалпы саганың мерзімі.
• Оқиғалар келісімшарттары нұсқаланған, схеманың валидациясы бар.
• DLQ және қауіпсіз редрайв теңшелген.
• Телеметрия: метрика, трейсинг, корреляция 'saga _ id'.
• Операциялық playbooks: қолмен cancel/force-confirm, «ілінген» сағаларды бояу.
• Хаос және жүктеме тесттері өтеді, SLO/қателер бюджеті анықталған.

16) Типтік қателер

Компенсатор жоқ немесе ол «таза емес» (жанама әсерлері бар).
Демпотенттік/дедуп-дубль және жай-күйлердің «тербелісі» жоқ.
«Дастандағы сага» айқын шекарасыз - циклдар мен өзара бұғаттаулар.
Ешқандай мерзім жоқ → «мәңгілік» сағалар мен ресурстардың жылыстауы.
Оркестратор тұрақты күйсіз «есте» күйін сақтайды.
Телеметрия орталығынсыз хореография → «көзге көрінбейтін» іркілістер.
Мөлдір емес UX: пайдаланушылар аралық күйді көрмейді.

17) Жылдам рецепттер

SaaS классикасы: оркестрлеу + outbox/inbox, экспоненциалды backoff, DLQ, саганың UI-дегі мәртебесі.
Ресурс үшін күшті инварианттар: TTL резервімен TCC және GC Cancel.
Жоғары көлем/жүктеме: оқиғалар хореографиясы + қатаң теңсіздік және кілт бойынша метрика.
Мульти-өңір: жергілікті сагалар + соңғы агрегаттар; жаһандық бұғаттаудан аулақ болу керек.

Қорытынды

Сағалар - бұл жаһандық бұғаттаусыз бөлінген жүйелерде болжамды үйлесімділікті алудың тәсілі. Нақты компенсаторлар, іспеттілік, сенімді жеткізу (outbox/inbox), таймауттар мен ретрайлардың тәртібі, оған қоса телеметрия мен плейбуктер - күрделі бизнес-процестердің жүктеменің, сервистер мен географиялар санының өсуі кезінде тұрақты және оқылатын болуының кілті.