Dönüşüm Günlüğü: Parantez — Saga Pattern, ya da “Bu İşi Kim Yönetecek?”

Geçen yazıda bir servis çöktüğünde sistemin nasıl ayakta kalacağını konuştuk. Timeout, Retry, Circuit Breaker — güzel bir savunma hattı kurduk. Şimdi bir adım geri çekilip şunu soralım:

Peki ya hiçbir servis çökmedi, hepsi sağlıklı çalışıyor, ama iş akışının ortasında bir şeyler ters gittiyse?

Ödeme alındı. Güzel. Kargo oluşturuldu. Süper. Ama stok yok.

Şimdi ne yapacaksın?

İşte tam burada klasik veritabanı transaction’ları seni terk eder. Çünkü artık tek bir veritabanın değil, her biri kendi veritabanına sahip üç farklı servisin içindesin. BEGIN TRANSACTION yazıp ROLLBACK diyemezsin — o lüks gitti.

Saga Pattern tam bu noktada sahneye çıkıyor.

Saga Nedir?

Tek bir büyük ACID transaction yerine, her servisin kendi local transaction’ını yaptığı ve bir şeyler ters gittiğinde compensating transaction’larla geri sardığın bir zincir.

Yani Saga, dağıtık bir iş akışını küçük, yönetilebilir adımlara böler. Her adım bağımsız commit edilir. Hata olursa klasik rollback değil, iş mantığı seviyesinde geri alma devreye girer.

Saga’nın iki ana yaklaşımı var. Ve ikisi de aslında şu soruya farklı cevaplar veriyor: “Bu işi kim yönetecek?”

1. Choreography — “Herkes kendi işini bilir”

Merkezi bir yönetici yok. Her servis işini bitirince bir event yayınlar, bir sonraki servis o event’i dinler ve devreye girer. Kimse kimseye emir vermiyor; herkes sözleşmeyi biliyor ve ona göre hareket ediyor.

OrderService → [OrderCreated] → PaymentService → [PaymentCompleted] → ShippingService

Kulağa hoş geliyor — özgür, bağımsız, dağıtık. Ve küçük iş akışları için gerçekten hoş.

Ama iş akışı büyüdükçe bir sorun çıkıyor: kim neyi ne zaman yaptı? Event’ler ortalığa saçılmış, her servis kendi köşesinde bir şeyler yapıyor. Bir hata olduğunda debug etmek, dedektiflik yapmaya dönüşüyor.

2. Orchestration — “Bir orkestratör var, o bilir”

Merkezi bir Saga Orchestrator tüm adımları yönetir. Hangi servisin ne zaman çağrılacağını, hata olursa ne yapılacağını o bilir. Servisler sadece kendilerine söylenen işi yapar — büyük resmi görmelerine gerek yok.

SagaOrchestrator → PaymentService
                       ↓ başarılı
                   ShippingService
                       ↓ başarısız
                   OrderService.Cancel()  ← compensating

Daha fazla kontrol, daha kolay takip, daha net hata yönetimi. Ama tabii bir bedeli var: orkestratör kritik bir bileşen haline geliyor. Hem merkezi bilgi noktası hem de potansiyel tek hata noktası.

Compensating Transaction — Rollback Değil, Özür Dilemek

Bu kavramı doğru anlamak önemli. Compensating transaction bir rollback değil.

Rollback, hiçbir şey olmamış gibi geri döner. Compensating transaction ise “oldu, ama düzeltelim” der. İş mantığı seviyesinde bir geri alma.

E-ticaret senaryomuzdan gidelim:

1. Sipariş oluşturuldu ✓
2. Ödeme alındı ✓
3. Stok rezerve edilmeye çalışıldı — stok yok ✗

Şimdi ne olacak? Veritabanında rollback yok. Ödeme gerçekleşti bile. Compensating transaction devreye girer:

• RefundPayment() → ödemeyi iade et
• CancelOrder() → siparişi iptal et

Kulağa basit geliyor ama dikkat: her adımın bir compensating action’ı olmalı ve bu action idempotent olmalı. Yani aynı işlemi iki kez çalıştırsan da sonuç değişmemeli — çünkü dağıtık sistemlerde aynı mesaj iki kez gelebilir.

Choreography mu, Orchestration mu?

İkisi arasında seçim yaparken şu soruları sor:

Choreography Orchestration Yönetim Dağıtık, event-driven Merkezi orkestratör Görünürlük Düşük — event’ler dağınık Yüksek — tek noktadan takip Karmaşıklık Basit akışlarda düşük Karmaşık akışlarda daha iyi Bağımlılık Servisler event contract’a bağlı Servisler orkestratöre bağlı Debug Zor Kolay

Kural olarak: 2–3 servis, basit akış → Choreography yeter. Birden fazla karar noktası, hata senaryoları, SLA taahhüdü → Orchestration daha güvenli.

Saga Ne Zaman Lazım?

Her dağıtık iş akışı Saga gerektirmez. Ama şu işaretleri görüyorsan Saga’yı düşünme vakti gelmiştir:

• Birden fazla servisin dahil olduğu, sıralı adımlardan oluşan bir iş akışın var
• Bu adımlardan biri başarısız olunca önceki adımların geri alınması gerekiyor
• Tek bir distributed transaction kullanamıyorsun — zaten kullanmamalısın da

Sonuç

Saga Pattern, dağıtık sistemlerde “ya hep ya hiç” garantisini farklı bir şekilde sağlar: tek bir büyük transaction yerine, her adımın kendi sorumluluğunu aldığı ve hata olursa kibarca geri çekildiği bir zincir.

Choreography sana özgürlük verir — ama takip etmesi güçtür. Orchestration sana kontrol verir — ama merkezi bir bileşene bağımlısın.

Hangisini seçersen seç, şunu unutma: compensating transaction’lar iyi tasarlanmamışsa Saga bir çözüm değil, yeni bir problem kaynağı olur.

Serinin diğer makalelerine profilimden ulaşabilirsiniz.

Medium tags: Saga Pattern · Microservices · Distributed Systems · Software Architecture · Event Driven Architecture

LinkedIn paylaşımını da hazırlayayım mı?