Dağıtık Saga Orkestrasyonu: Telafi Edici İş Akışları (Compensating Actions) ve Zaman Aşımı Kilitlenmeleri

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

Mikroservis mimarisinde birden fazla servise yayılan iş süreçleri (Sipariş -> Ödeme -> Stok -> Kargo), servisler arası gecikme ve kilitlenme riskleri yüzünden geleneksel ACID Two-Phase Commit (2PC) kullanamaz. Saga Deseni, dağıtık işlemi bir Orkestratör (Temporal, AWS Step Functions) tarafından yönetilen yerel işlemler zincirine böler. Bir adım başarısız olduğunda (ör. Stokta Yok), Orkestratör geriye doğru 'Telafi Edici İşlemleri' (Compensating Transactions - Parayı İade Et, Siparişi İptal Et) çalıştırır. Ancak en tehlikeli kriz 'Zaman Aşımı Belirsizliğinde' (Timeout Ambiguity) çıkar: Ödeme servisi kilitlenip zaman aşımına uğradığında, paranın çekilip çekilmediği bilinemez. Güvenilir Saga mimarileri bunu kesin Idempotency Anahtarları, telafiden önce eksponansiyel retry yapan Dayanıklı Durum Makineleri (Durable Execution) ve insan müdahalesi gerektiren Dead-Letter Queue (DLQ) kuyruklarıyla çözer.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Dayanıklı Saga Orkestrasyonu 4 temel garantiye dayanır:

Orkestratör Durum Kaydı: Her adım RPC çağrısı yapılmadan önce değişmez bir olay geçmişine (Temporal Event History) diske yazılır.

Idempotent Telafi İşlemleri: Her telafi adımı (refundPayment(orderId, idempotencyKey)) matematiksel olarak idempotent olmak ve 100 kez tekrarlansa bile aynı sonucu üretmek zorundadır.

İleriye Kurtarma vs Geriye Telafi: Geçici ağ zaman aşımlarında orkestratör ileriye doğru retry yapar; geriye doğru telafi ise yalnızca 'Yetersiz Bakiye' gibi geri döndürülemez kesin iş mantığı hatalarında çalıştırılır.

Semantik Kilit: Fiziksel veritabanı kilitleri yerine varlıklar PENDING (Beklemede) durumuna alınır.

🎯2. Doğru Kullanım Senaryosu

Kapsam

E-ticaret sipariş akışları, ödeme işleme ağ geçitleri, çok adımlı SaaS kullanıcı kayıt süreçleri ve seyahat/otel rezervasyon sistemleri.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Idempotent olmayan bir telafi fonksiyonunun ağ retry'ı sırasında müşteriye 5 kez üst üste para iadesi yapması
✓
orkestratör sunucusunun durum kaydı tutmadan çökmesi sonucu 10.000 siparişin stoklarının rezerve kalıp paralarının çekilememesi
✓
mesaj kuyruklarında kaybolan olaylar yüzünden sistemin yarım kalmış işlemlerden tamamen habersiz olması

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
Finans ve stok veritabanları arasında mutabakat uyuşmazlıkları
✓
müşterilerin kartından para çekilip siparişin oluşmaması şikayetleri
✓
veritabanında günlerdir PENDING durumunda asılı kalan binlerce işlem

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Gelişigüzel kuyruklar yerine Kod Olarak Yapılandırılan Dayanıklı Yürütme (Durable Execution - Temporal.io / Step Functions) motorları kullanın
✓
tüm dış API çağrılarında zorunlu Idempotency-Key başlığı uygulayın
✓
1 saati aşan açık Sagalar için otomatik alarm kurun

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Saga orkestrasyonu her adım için karmaşık telafi iş mantıkları yazmayı ve test etmeyi gerektirir; ancak mikroservislerin dağıtık veritabanı kilitlenmelerine boğulmadan bağımsızca ölçeklenmesini sağlar.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir seyahat platformu Uçak -> Otel -> Araç Kiralama adımlarını Temporal ile yönetiyordu. Otel servisi çöktüğünde API 30 saniye zaman aşımına uğradı. Temporal iş akışı dayanıklı (durable) olduğu için paniklemedi: Otelin idempotent sorgu API'sine sorup odanın tutulmadığını teyit etti; ardından geriye doğru uçak rezervasyonunu iptal edip parayı iade etti. Müşteriye anında bilgi verildi ve arkada hiçbir yetim bilet kalmadı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Dağıtık Saga deseninde 'Telafi Edici İşlem' (Compensating Transaction) nedir?

İş akışının sonraki bir adımı başarısız olduğunda, daha önce başarıyla tamamlanmış yerel adımların etkilerini semantik olarak geri alan (ör. para iadesi, sipariş iptali) işlemdir.

Bir Saga'daki tüm telafi işlemlerinin kesinlikle 'Idempotent' olması neden ŞARTTIR?

Çünkü ağ zaman aşımları orkestratörün telafi işlemini birden fazla kez çalıştırmasına yol açabilir; idempotent olmayan bir iade müşteriye mükerrer para iadesi yapılmasına neden olur.

Dağıtık Saga Orkestrasyonu: Telafi Edici İş Akışları (Compensating Actions) ve Zaman Aşımı Kilitlenmeleri — Sıkça Sorulan Sorular

Saga Orkestrasyonu ile Saga Koreografisi (Choreography) arasındaki fark nedir?

Orkestrasyon her adımı merkezi bir koordinatör (Temporal) ile açıkça yönetir; Koreografi ise merkezi bir yönetici olmadan servislerin asenkron olaylar yayınlayıp dinlemesine dayanır.

Dağıtık Sagalar bağlamında Temporal.io nedir?

Sunucu çöküşlerinde ve ağ bölünmelerinde kodun tüm çalışma durumunu, değişkenlerini ve retry geçmişini hafızada koruyan açık kaynaklı bir Dayanıklı Yürütme (Durable Execution) platformudur.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
Distributed Sagas replace distributed ACID 2PC with local transactions and compensations.
▸
Compensating actions semantically undo committed steps when a workflow fails.
▸
All compensating actions MUST be strictly idempotent with unique Idempotency Keys.
▸
Durable execution engines (Temporal/Step Functions) prevent abandoned transactions during crashes.

Yaygın Yanılgılar

✗
Yanılgı: A Saga guarantees ACID isolation (Gerçek: Sagas lack isolation; dirty reads can occur unless semantic locks are used).
✗
Yanılgı: Sagas should compensate immediately on network timeout (Gerçek: Sagas should retry forward with jitter before assuming a terminal business failure).

Karar Kılavuzu & Önceliklendirme

Adopt Orchestrated Sagas via Temporal.io for mission-critical payment and multi-service workflows. Require an Idempotency-Key header on all microservice mutating endpoints.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]Sagas: Distributed Long-Lived Transactions Architecture— Hector Garcia-Molina & Kenneth Salem (Princeton University)

Bu sayfadaki teknik terimler

Idempotency