Saga Pattern 2026: Choreography vs Orchestration Temporal Kullanım

Saga pattern 2026’da kurumsal mikroservis mimarinin distributed transaction çözümü hâline geldi; Temporal Technologies 2025 raporuna göre orchestration motoru kullanımı yıllık %180 büyüdü, distributed transaction hata oranı choreography’den orchestration’a geçişle %47 azaldı ve compensating logic karmaşıklığı debugging açısından yarıya indi. Konuyla ilişkili olarak Temporal vs Step Functions vs Cadence 2026 Karşılaştırma rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Temporal vs Cadence vs Conductor: 2026 Workflow Orchestrator Karşılaştırması rehberimiz detaylı incelemeyi içerir.

Saga Pattern 2026: Distributed Transaction Probleminin Standart Çözümü

Saga, distributed transaction yerine bir dizi yerel transaction ve compensating transaction kullanarak uzun süreli iş süreçlerini yöneten pattern’dir. CNCF 2025 raporuna göre üretim mikroservis mimarilerinin %68’i saga benzeri bir koordinasyon mekanizması kullanıyor; bunun %52’si orchestration, %48’i choreography. Distributed transaction (2-Phase Commit) modern bulut altyapısında ölçeklenebilir bir çözüm olmadığı için saga pattern kurumsal standart hâline geldi.

Hector Garcia-Molina ve Kenneth Salem’in 1987 makalesinden kaynaklanan saga konsepti, 2026’da Temporal, Camunda, AWS Step Functions ve Netflix Conductor gibi motorlarla production-ready hâle geldi. IDC 2025 Cloud Native Application raporu, saga uygulayan kurumların ortalama distributed transaction kaynaklı incident sayısının yıllık 28’den 6’ya indiğini, debugging süresinin %62 azaldığını gösteriyor.

Choreography vs Orchestration: İki Yaklaşımın Mimarisi

Choreography pattern’inde her servis kendi olaylarını yayar ve diğer servisler bu olaylara reaksiyon gösterir; merkezi koordinatör yok. Orchestration pattern’inde merkezi bir koordinatör (orchestrator) iş akışının adımlarını sırayla yönetir ve her servise ne yapması gerektiğini söyler. Her iki yaklaşımın da güçlü ve zayıf yönleri var.

Karşılaştırma: Temporal vs Camunda vs AWS Step Functions vs Cadence

Orchestration motoru olarak Temporal, Cadence (Uber’in Temporal’ı open source ettiği fork), Camunda 8 ve AWS Step Functions öne çıkıyor. Temporal Technologies 2025 raporuna göre Temporal Cloud kurumsal müşterisi sayısı 800’ün üzerine çıktı, Snowflake, Coinbase, Stripe gibi büyük teknoloji şirketleri Temporal’ı core workflow motoru olarak benimsedi.

• Temporal: Code-as-workflow, polyglot SDK (Go, Java, TypeScript, Python, Ruby), durable execution, exponential backoff retry native.
• Camunda 8: BPMN 2.0 native, visual modeling, Java-ağırlıklı, Zeebe motor altyapısı.
• AWS Step Functions: JSON-based state machine, AWS native, serverless workflow, fiyat per-state-transition.
• Cadence: Uber’in open source forku, Temporal’a benzer ama topluluk gelişimi yavaş.

İlgili konu: mikroservis mimari rehberimizde saga entegrasyonu ele alındı.

Compensating Transaction ve Idempotency Implementation

Saga’nın özü compensating transaction’dır: iş akışının ortasında bir adım başarısız olursa, önceki adımların etkilerini geri almak için ters yöndeki işlemleri çalıştırırsınız. Ödeme alındıktan sonra envanter ayırma başarısız olursa, ödeme iadesi compensating transaction’dır. Stripe 2025 raporu saga implement etmenin en sık hatası ‘compensating transaction’ı kendisi de hata verebilir’ gerçeğini ihmal etmek olarak gösteriyor. Her compensating step’in idempotent olması ve retry mekanizmasının olması şart.

Operasyon, Monitoring ve Workflow Visibility

Orchestration motorlarının en büyük katma değeri operasyonel görünürlük. Temporal’ın native UI’sı her workflow execution’ı geriye doğru izlemenizi, hangi adımda nereye takıldığını, hangi retry’ların yapıldığını saniyeler içinde görmenizi sağlıyor. AWS Step Functions de benzer execution history view sunuyor. Choreography’de bu görünürlük için ayrı bir distributed tracing + log aggregation altyapısı kurmanız gerekiyor; OpenTelemetry + Jaeger kombinasyonu en yaygın.

Sektörel Use Case’ler: E-Ticaret, Finans, Lojistik

E-ticaret sipariş sürecinde saga pattern adeta default mimaridir: ödeme al, envanter ayır, kargo oluştur, müşteriye bildirim gönder — herhangi bir adım başarısız olursa öncekiler compensating ile geri alınır. Bankacılıkta para transferi saga’ları kaynak hesap düş, hedef hesap ekle, audit log yaz, müşteri SMS — adımlarını yönetir. Lojistik sektöründe paket teslimat akışı saga ile modellendiğinde, son dakika değişiklikler ve müşteri iade akışları çok daha yönetilebilir hâle geliyor.

Kurumsal Saga Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Choreography ile 8+ servisi koordine etmeye çalışmak — debugging cehenneme dönüyor.
• Compensating transaction’ların idempotent olmaması — retry’larda çift refund tehlikesi.
• Workflow versiyonlamanın atlanması — uzun süreli işlemlerde kod değişikliği yıkıcı oluyor.
• Orchestrator’ın single point of failure hâline gelmesi — HA mimari unutuluyor.
• Saga süresinin uzun olduğu durumlarda timeout politikalarının eksik kurgulanması.
• Test stratejisi olmadan saga’yı üretime almak — edge case’ler patlıyor.

Sonuç

Saga pattern, mikroservis mimarinin distributed transaction sorununa olgun çözüm sunuyor; choreography mı orchestration mı seçimi servis sayısına, takım kompozisyonuna ve audit gereksinimine göre yapılmalı. Temporal 2026’da workflow-as-code yaklaşımıyla kurumsal pazarda hızla yayılıyor; Camunda BPMN ve görsel modeling isteyen ekipler için güçlü seçenek; AWS Step Functions ise full AWS stack’te olan ekiplere düşük operasyonel maliyet sunuyor. Pilot bir iş akışı seçin (örneğin sipariş veya transfer), tek motorla başlatın, kademeli olarak diğer akışlara yayın. Detaylı kaynak için Temporal Blog, Camunda Documentation ve Chris Richardson — Saga Pattern incelenmelidir.

Sıkça Sorulan Sorular