Saga Pattern Nedir?
26 Ekim 2026 Pazartesi
Dağıtık Sistemlerde İşlemleri Geri Alma Sanatı.
Monolitik mimarilerde ilişkisel bir veritabanı (RDBMS) üzerinde çalışırken hayat oldukça konforludur. Bir sipariş sürecinde stok düşülür, ödeme alınır, fatura kesilir. Bu adımlardan herhangi birinde hata çıkarsa veritabanına tek bir komut veririz: ROLLBACK. İşlem hiç gerçekleşmemiş gibi başa sarar ve veri tutarlılığı (ACID) tereyağından kıl çeker gibi korunur.
Ancak mikroservis dünyasına geçip her servise kendi veritabanını (Database-per-Service) verdiğimizde bu ACID lüksü bir anda buharlaşır.
Sipariş Servisi siparişi oluşturmuş, Ödeme Servisi karttan parayı çekmiş, ancak Kargo Servisi çöktüğü için teslimat oluşturulamamış olabilir. Elinizde 3 farklı servise ait 3 ayrı veritabanı varken tek bir ROLLBACK komutu çalıştıramazsınız.
Geleneksel dağıtık işlem protokolleri (Two-Phase Commit - 2PC) ise servisleri birbirine kilitlediği, aşırı yavaşlattığı ve tek bir hata anında tüm sistemi tıkadığı için modern bulut mimarilerinde tercih edilmez.
İşte mikroservislerde dağıtık transaction (işlem) yönetiminin ve veri tutarlılığının endüstri standardı çözümü: Saga Pattern.
Saga Pattern Nedir?
Saga Pattern; birden fazla mikroservise yayılan karmaşık bir iş sürecini, bir dizi sıralı ve bağımsız yerel işleme (local transaction) bölen ve süreçte bir hata meydana geldiğinde önceki adımların etkisini tersine çevirmek için telafi edici işlemler (compensating transactions)tetikleyen bir dağıtık işlem yönetimi kalıbıdır.
Saga mimarisinde her bir servis kendi yerel veritabanında işlemi tamamlar ve bir sonraki servisi tetikleyen bir olay (event) fırlatır. Süreç sonuna kadar başarıyla giderse işlem tamamlanır.
Ancak ara adımlardan birinde hata çıkarsa, Saga zinciri geriye doğru işletilir. Tıpkı bir filmi geri sarmak gibi, o ana kadar başarılı olmuş tüm adımlar için özel olarak yazılmış "geri alma / iptal" fonksiyonları devreye girer.
Saga Pattern Nasıl Uygulanır? (2 Temel Yaklaşım)
Saga kalıbını hayata geçirmek için kullanılan iki ana yöntem vardır:
1. Choreography (Koreografi - Olay Güdümlü)
Merkezi bir yönetici veya koordinatör yoktur. Servisler bir mesaj kuyruğu (Kafka, RabbitMQ) üzerinden birbirlerinin fırlattığı olayları (events) dinleyerek ne yapacaklarına kendileri karar verir.
- Nasıl Çalışır?: Sipariş Servisi SiparisOlusturuldu olayını fırlatır. Bunu dinleyen Ödeme Servisi parayı çeker ve OdemeAlindi olayını fırlatır. Stok servisi bunu duyar ve stoğu rezerve eder.
- Artıları: Basit akışlarda kurulumu hızlıdır, merkezi bir bağımlılık yoktur.
- Eksileri: Adım sayısı arttıkça hangi servisin neyi dinlediğini takip etmek zorlaşır, "olay spagettisi" oluşabilir.
2. Orchestration (Orkestrasyon - Merkezi Yönetici)
Tüm süreci yöneten merkezi bir "Orkestratör" (State Machine / Akış Yöneticisi) bulunur. Servislere sırayla ne yapmaları gerektiğini doğrudan söyler.
- Nasıl Çalışır?: Orkestratör servis, Ödeme Servisi'ne "Ödemeyi al" der. Başarılı yanıt gelince Stok Servisi'ne "Stoğu düş" der. Stok servisi hata dönerse, orkestratör hemen Ödeme Servisi'ne "Parayı iade et" emrini iletir.
- Artıları: Karmaşık iş akışlarında kontrol tamamen tek bir yerdedir, sürecin hangi adımda kaldığını izlemek çok kolaydır.
- Eksileri: Orkestratör servisin çökmemesi ve yüksek erişilebilir (HA) tasarlanması gerekir.
Telafi İşlemi Tasarlarken Dikkat Edilmesi Gerekenler
Bir telafi işlemi (compensating transaction) tasarlamak her zaman "silme" işlemi yapmak demek değildir:
- Yan Etkiler Geri Alınamaz: Müşteriye "Ödemeniz alındı" e-postası veya SMS'i gittiğinde bunu geri çekemezsiniz. Telafi adımı olarak "Pardon, sistemsel bir hata nedeniyle siparişiniz iptal edildi" bilgilendirmesi tetiklenmelidir.
- Idempotency Şarttır: İptal veya telafi komutları ağ kesintileri nedeniyle birden fazla kez tetiklenebilir. Bu nedenle telafi servislerinin mutlaka Idempotent tasarlanması gerekir.