1. GİRİŞ

Saga Pattern, mikroservis mimarilerinde dağıtık işlemleri yönetmek için geliştirilmiş uygulama düzeyi bir desendir. Tek bir veritabanı sınırları içinde kolayca yönetilebilen ACID transaction'ların aksine, mikroservisler birbirinden bağımsız veri sahipliğine sahip olduğunda tüm adımları tek bir atomik işlemde tutmak hem pratik hem de performans açısından zordur. Saga, uzun süreli iş akışlarını lokal, küçük transaction'lara bölerek ve başarısızlık durumlarında compensation (telafi) adımlarıyla tutarlılık sağlamayı amaçlar.

Bu konu neden bugün önemli?

• Mikroservislerin yaygınlaşmasıyla veri ownership dağıldı; uçtan uca işlemler artık birden çok servis ve veri mağazası üzerinde gerçekleşiyor.
• Bulut yerel uygulamalar, event-driven mimariler ve serverless yaklaşımlar uzun süreli, stateful iş akışlarını uygulama düzeyinde yönetme ihtiyacını arttırdı.
• Performans, availability ve operasyonel gözlemlenebilirlik gereksinimleri klasik 2PC türü bloklayıcı protokolleri kabul edilemez kılıyor.

Kimler için önemli?

• Çözüm mimarları ve yazılım mimarları
• Backend geliştiriciler ve entegrasyon mühendisleri
• SRE/Platform ekipleri ve test mühendisleri
• Ürün sahipleri: iş süreçlerinin bütünlüğü ve izlenebilirliği için

Hangi problemleri çözüyor?

• Dağıtık hata durumlarında veri tutarlılığını sağlama
• Long-running workflows yönetme
• Performansı koruyarak blocking protokoller yerine uygulama düzeyinde esneklik sağlama

2. KAVRAMSAL TEMELLER

Saga'yı doğru uygulamak için temel kavramları ve terminolojiyi netleştirmek gerekir. Bu terminoloji, tasarım ve operasyon kararlarında yol gösterir.

2.1. Ana Tanımlar

• Saga: Bir iş akışını oluşturan bir dizi lokal transaction (adım). Her adım başarılıysa bir sonraki adım çalışır; başarısız olursa önceki başarılı adımların telafi işlemleri (compensation) çalıştırılır.
• Compensation: Başarısız bir saga adımı sonrası yapılan, önceki adımın etkisini geri almak için uygulanan işlem veya işlemler dizisi.
• Orchestration: Merkezî bir orchestrator bileşenin saga adımlarını yönettiği uygulama şekli.
• Choreography: Her servisin kendi event'ini yayınladığı ve diğer servislerin bu event'leri dinleyerek hareket ettiği dağıtık uygulama şekli; merkezi orchestrator yoktur.
• Outbox Pattern: Lokal transaction ile event publish arasındaki atomikliği sağlayan desen. Değişiklik önce outbox tablosuna yazılır, daha sonra arka plan işlemi bu outbox'tan mesajı broker'a yollar.
• Idempotency: Aynı isteğin birden çok kez işlendiğinde yan etkisinin tek seferlik olmasını sağlamaya yönelik mekanizmalar.

2.2. Neden 2PC yerine Saga?

• 2PC gibi coordinator-based protokoller bloklayıcı olabilir; ağ veya participant arızası tüm transaction'ı durdurabilir.
• Coğrafi dağıtımlarda 2PC yüksek latency ve availability problemlerine yol açar.
• Saga non-blocking, mikroservis dostu ve event-driven mimarilerle daha iyi uyum sağlar; compensating transaction'lar kullanılarak esneklik sunar.

3. NASIL ÇALIŞIR?

Saga uygulama adımları, orchestration vs choreography farkları, event akışları ve telafi mekanizmaları ile birlikte incelenmelidir. Bu bölümde teknik mimari, veri akışı ve hata senaryolarını ele alıyoruz.

3.1. Orchestration Yaklaşımı

Orchestration modelinde merkezi bir orkestratör (durable workflow engine veya custom orchestrator) vardır. İş akışı bu bileşen tarafından adım adım tetiklenir. Orkestratör, hangi servis çağrılacak, hangi event'ler publish edilecek ve herhangi bir adım başarısız olursa hangi compensation çalıştırılacağına karar verir.

• Avantajları: Kolay gözlemlenebilirlik, merkezi hata yönetimi, daha deterministik yürütme
• Dezavantajları: Orkestratör tek bir koordinasyon noktası olabilir; orkestratöre aşırı bağımlılık riskleri vardır

3.2. Choreography Yaklaşımı

Choreography modelinde merkezi orkestratör yoktur. Her servis kendi domain event'lerini yayınlar; diğer servisler bu event'leri dinleyerek kendi işleri yapar. Örneğin "OrderCreated" event'i yayınlandığında ödeme servisi, envanter servisi veya faturalama servisi buna tepki verebilir.

• Avantajları: Daha gevşek bağlılık, merkezi koordinatör yok, doğal event-driven mimari
• Dezavantajları: Zaman içinde karmaşık event graph'lar, hata senaryoları ve ordering sorunları zor yönetilebilir

3.3. Tipik Veri Akışı — Örnek: E‑commerce Sipariş

1. Kullanıcı sipariş oluşturur — Order Service: lokal transaction ile sipariş kaydı oluşturulur ve "OrderCreated" event'i outbox'a yazılır.
2. Outbox worker event'i broker'a publish eder.
3. Payment Service "OrderCreated" event'ini alır, ödeme işlemini yapar; başarılıysa "PaymentCompleted" publish eder, başarısızsa "PaymentFailed" ve orchestrator/consumer compensation tetikler.
4. Inventory Service "PaymentCompleted" alırsa stoğu düşürür; başarısız olursa compensation adımları tetiklenir (örn. refund veya order cancel).
5. Tüm adımlar başarılıysa sipariş tamamlanır; adımlardan herhangi birinde hata olursa ilgili compensation adımları çalıştırılarak sistem tutarlı hale getirilir.

3.4. Compensation (Telafi) Stratejileri

Compensation adımları, orijinal adımların tersini uygulamaktan daha fazlasıdır; iş mantığına özgü düzeltmeler gerekir. Örneğin; stok düşürüldüyse stok geri konmalı, ödeme yapıldıysa iade süreci başlatılmalıdır. Compensation görevleri idempotent olmalıdır ve başarısızlık durumlarına göre yeniden denenmeli veya insan müdahalesine düşmelidir.

3.5. Outbox Pattern ve Atomic Event Publish

Outbox Pattern, lokal veri değişikliği ile event publish arasındaki atomikliği sağlar. Lokal transaction içinde değişiklik ve outbox yazılır. Ardından arka plan işçisi outbox'tan reliable bir biçimde mesajı broker'a gönderir. Bu desen duplicate mesajlara karşı dayanıklı olmak için idempotency ile birlikte kullanılır.

3.6. Idempotency ve Duplicate Delivery

Mesaj broker veya network nedeniyle mesaj tekrar gelebilir. Herhangi bir endpoint idempotent olmalı veya idempotency token'ları kullanarak duplicate side-effects engellenmelidir. Idempotency tabloları ya da request ID bazlı deduplication yaygın tekniklerdir.

4. GERÇEK DÜNYA KULLANIMLARI

Büyük ölçekli üretim sistemlerinde Saga pattern hangi durumlarda tercih edilir? Aşağıda sektörel örnekler ve pratik yaklaşımlar bulunmaktadır.

Netflix

Netflix hizmetlerinin çoğu event-driven ve eventual consistency ile çalışır. Uzun süreli kullanıcı işlemleri için compensation-based desenler ve event choreography tercih edilir; bu sayede sistem ölçeklenebilir ve resilient olur.

Uber

Dispatch ve lokasyon temelli işlerde lokality önemlidir. Uber, bazı kritik path'leri koordinasyon ile yönetirken, çoğu asenkron iş akışını saga benzeri patternlerle çözer; compensation ve idempotency mekanizmaları operasyonel olarak sıkı tutulur.

Amazon (AWS)

AWS Step Functions veya Durable Functions gibi serverless workflow hizmetleri, orchestration yaklaşımını sunar. Enterprise müşteriler kompleks uzun süreli işlemlerini bu hizmetlerle modelleyip izleyebilirler. Outbox pattern, SQS/SNS ile birlikte sık kullanılan bir kombinasyondur.

Stripe

Ödemede kesin tutarlılık gerekse de Stripe gibi firmalar domain-level idempotency, rekonsiliasyon ve audit süreçleriyle dağıtık işlemleri güvenli hale getirir. Bazı işlemler için güçlü transaction garanti mekanizmaları veya manuel reconciliation süreçleri konulur.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Non-blocking: 2PC gibi bloklayıcı protokollere göre daha yüksek availability sağlar.
• Microservice-friendly: Her servis kendi bounded context'inde hareket eder.
• Performans: Lokal transaction'lar kısa sürelidir; coğrafi dağıtımda daha iyi gecikme davranışı sunar.

Sınırlamalar

• Compensation logic karmaşıktır ve domain bilgisi gerektirir.
• Event ordering, idempotency ve duplicate mesaj yönetimi operasyonel yük getirir.
• Otomatik analiz ve hata tespiti için iyi izleme ve tracing gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo dağıtık transaction ihtiyaçları için yaygın yaklaşımları karşılaştırır.

7. EN İYİ PRATİKLER

Saga pattern tasarlarken ve işletirken dikkat edilmesi gereken pratik tavsiyeler aşağıdadır. Kod örneği yoktur; mimari, operasyon ve güvenlik tavsiyelerine odaklanıyoruz.

Production Kullanımı

• Transaction boundary'lerini küçük tutun; mümkünse tek bir servis içinde tutacak şekilde domain modellerini yeniden şekillendirin.
• Veri ve iş sınıflandırması yapın: Hangi işlemler compensation gerektirebilir ve hangileri kesin atomicity şart?
• Orchestrator kullanıyorsanız stateless orchestrator'lar yerine durable workflow engine tercih edin; state'i her adım sonrası persist edin.

Performans Optimizasyonu

• Outbox pattern ve message batching ile publish maliyetlerini düşürün.
• Idempotency token'ları ve deduplication tabloları ile duplicate processing maliyetini azaltın.
• Event ordering gerektiğinde partitioning ve key'leme stratejileri ile garanti altına alın.

Güvenlik

• Workflow ve orchestrator bileşenlerine erişim kontrolleri uygulayın; audit logging zorunlu olsun.
• Mesaj kanalları TLS/mTLS ile korunmalı; sensitive data masking ve PII politikaları uygulanmalıdır.

Ölçeklenebilirlik ve Operasyon

• Tracing: Saga düzeyinde correlation ID, span ve event bağlama ile end-to-end visibility sağlayın.
• Monitoring: Saga başarısızlık oranı, compensation count, average saga duration gibi metrikleri toplayın.
• Runbooks: Compensation senaryoları için insan müdahalesi gerektiren durumlar adına operasyonal playbook'lar hazırlayın.

8. SIK YAPILAN HATALAR

• Compensation logic yazmamayı veya yetersiz test etmeyi ihmal etmek
• Idempotency politikası olmadan outbox veya broker kullanımına geçmek
• Event ordering gereksinimlerini başlangıçta belirlememek; sonradan zorlayıcı düzeltmeler yapmak
• Observability, tracing ve alerting olmadan uzun süreli workflow'ları işletmek
• Orkestratörü tek hata noktası haline getirmek veya orchestrator state'ini persist etmemek

9. GELECEK TRENDLER

AI‑Assisted Workflow Optimization

ML modelleri workflow performansını izleyerek bottleneck tespiti, compensation tetikleme optimizasyonu ve re-run önerileri sunacak. Bu, özellikle büyük orkestratör kümeleri için operasyonel yükü azaltabilir.

Serverless Durable Workflows ve Managed Services

Serverless sağlayıcıların durable workflow hizmetleri daha fazla benimseniyor; geliştiriciler workflow state yönetimini servis sağlayıcıya bırakıp uygulama mantığına odaklanabilecek.

Saga Orchestration için Standart Araçlar

Workflow DSL'leri, görsel tasarım araçları ve daha iyi test altyapıları saga adoption'ını kolaylaştıracak. Bu sayede compensation logic daha kolay yazılıp doğrulanabilecek.