Saga Pattern Nedir? Dağıtık İşlem Yönetimi Rehberi
Monolitik uygulamalarda veritabanı transaction'ları basittir: ya hepsi başarılı, ya hepsi geri alınır (ACID). Ama mikroservis mimarisinde her servisin kendi veritabanı var. Birden fazla servisi kapsayan bir işlemi nasıl yönetirsiniz?
Problem: Dağıtık Transaction
Bir e-ticaret sipariş akışını düşünün:
1. Sipariş Servisi → Sipariş oluştur
2. Ödeme Servisi → Ödemeyi al
3. Stok Servisi → Stok düş
4. Kargo Servisi → Kargolama başlat
- adımda stok yetersizse ne olacak? Ödeme alınmış, sipariş oluşturulmuş. Bunları geri almak lazım — ama her servis ayrı veritabanında!
Saga Pattern Çözümü
Saga Pattern, uzun süren bir iş sürecini küçük, yerel transaction'lara böler. Her adım ya başarılı olur ya da telafi edici işlem (compensating action) tetiklenir.
Başarılı akış:
T1 → T2 → T3 → T4 → ✅ Tamamlandı
Hata durumu (T3 hatalı):
T1 → T2 → T3 ❌ → C2 → C1 → ❌ Geri alındı
- T = Transaction (ileri adım)
- C = Compensating action (telafi)
İki Yaklaşım
1. Choreography (Koreografi)
Her servis bir olay yayınlar, diğer servisler bu olayı dinler ve tepki verir:
Sipariş Servisi: SiparişOluşturuldu →
Ödeme Servisi (dinler): ÖdemeAlındı →
Stok Servisi (dinler): StokDüşüldü →
Kargo Servisi (dinler): KargolamaBaslatildi
Hata durumu:
Stok Servisi: StokYetersiz →
Ödeme Servisi (dinler): ÖdemeIadeEdildi →
Sipariş Servisi (dinler): SiparişIptalEdildi
Avantajları:
- Basit, merkezi kontrol yok
- Servisler gevşek bağlı (loose coupling)
- Eklenmesi kolay
Dezavantajları:
- Akışı takip etmek zor
- Döngüsel bağımlılık riski
- Debug zorluğu
2. Orchestration (Orkestrasyon)
Merkezi bir Saga Orkestratör tüm akışı yönetir:
Saga Orkestratör:
1. → Sipariş Servisine: "Sipariş oluştur" → ✅
2. → Ödeme Servisine: "Ödeme al" → ✅
3. → Stok Servisine: "Stok düş" → ❌
4. → Ödeme Servisine: "Ödeme iade et" (telafi)
5. → Sipariş Servisine: "Sipariş iptal et" (telafi)
Avantajları:
- Akış açık ve merkezi
- Debug kolay
- Karmaşık akışlar yönetilebilir
Dezavantajları:
- Merkezi kontrol noktası (SPOF riski)
- Orkestratör karmaşıklaşabilir
- Servislere daha sıkı bağımlılık
Hangi Yaklaşımı Seçmeli?
| Kriter | Choreography | Orchestration | |--------|-------------|---------------| | Adım sayısı | 2-4 adım | 5+ adım | | Karmaşıklık | Düşük | Yüksek | | Servislerin bağımsızlığı | Yüksek | Orta | | Gözlemlenebilirlik | Zor | Kolay | | Yeni adım ekleme | Kolay | Orkestratör güncelleme gerekir |
Telafi Edici İşlemler
Her transaction'ın bir telafi işlemi olmalıdır:
| Transaction | Compensating Action | |-------------|-------------------| | Sipariş oluştur | Sipariş iptal et | | Ödeme al | Ödeme iade et | | Stok düş | Stok geri ekle | | Kargo başlat | Kargo iptal et |
Dikkat Edilmesi Gerekenler
- Telafi işlemleri idempotent olmalı (birden fazla çalıştırılabilmeli)
- Bazı işlemler geri alınamaz (e-posta gönderme) — alternatif telafi düşünün
- Timeout mekanizması ekleyin
Saga Pattern vs 2PC
| Özellik | 2PC (Two-Phase Commit) | Saga Pattern | |---------|----------------------|-------------| | Tutarlılık | Strong consistency | Eventual consistency | | Performans | Yavaş (locking) | Hızlı (lock yok) | | Ölçeklenebilirlik | Düşük | Yüksek | | Karmaşıklık | Orta | Yüksek (telafi mantığı) | | Uygunluk | Monolitik | Mikroservis |
Sonuç
Saga Pattern, mikroservis mimarisinde dağıtık transaction yönetiminin standart çözümüdür. Basit akışlar için Choreography, karmaşık akışlar için Orchestration tercih edilir.
Saga Pattern ve dağıtık sistem desenlerini LabLudus platformunda Architect kariyer yolunda interaktif olarak öğrenin. Yazılım Mimarisi 3.0 kitabında bu konuyu derinlemesine ele alıyoruz.