Dağıtık Sistemlerde Geriye Dönüş (Rollback) Sanatı: SAGA Mimarisi ve ERP Entegrasyonları

Monolitik bir uygulamada bir sipariş sürecini yönetmek çocuk oyuncağıdır; klasik bir RDBMS üzerinde bir BEGIN TRANSACTION başlatır, stok düşer, fatura keser ve her şey yolundaysa COMMIT edersiniz. Herhangi bir adımda hata olursa ROLLBACK ile tüm işlemler bir saniyeden kısa sürede hiç yaşanmamış gibi geri alınır.

Ancak günümüzün mikroservis mimarilerinde ve karmaşık ERP (Kurumsal Kaynak Planlama) entegrasyonlarında işler bu kadar basit değildir. Stok servisi ayrı bir veritabanında, ödeme servisi bir dış API'de, fatura modülü ise hantal bir ERP sisteminde yaşıyorsa, geleneksel 2PC (Two-Phase Commit) yaklaşımı sistemleri kilitler ve performansı çökertir. İşte tam bu noktada, uzun soluklu işlemleri (Long-Lived Transactions) yönetmek için Saga Deseni (Saga Pattern) devreye girer.

Saga Deseni Nedir?

Saga, dağıtık bir transaction'ı tek bir devasa işlem bloğu olarak tutmak yerine, her biri kendi yerel veritabanını güncelleyen bağımsız, ardışık yerel transaction'lar serisine (Local Transactions) böler.

Saga'nın kilit kuralı şudur: Eğer serideki işlemlerden biri başarısız olursa, Saga o ana kadar başarıyla tamamlanmış olan tüm önceki işlemleri geri almak için Telafi Edici İşlemler (Compensating Transactions) çalıştırır.

Saga Senaryosu: Bir Siparişin Hayat Eğrisi

Bir e-ticaret sistemindeki temel sipariş akışını düşünelim:

1. Sipariş Servisi: Siparişi Beklemede statüsünde oluşturur.

2. ERP / Stok Servisi: Ürünleri müşteriye rezerve eder (Stok düşülür).

3. Ödeme Servisi: Kredi kartından çekim yapar.

Diyelim ki 1. ve 2. adımlar başarılı oldu, fakat müşteri kredisiz olduğu için 3. adımda (Ödeme) hata aldık. Geleneksel veritabanı Rollback'i burada çalışmaz çünkü 2. adımdaki stok düşme işlemi ERP tarafında çoktan COMMIT edilmiştir.

Çözüm: Telafi Edici İşlemler (Compensating Transactions)

Saga mimarisinde her "Başarılı İleri Adım" (Do) için bir "Geri Alma Adımı" (Undo) yazmak zorundasınız.

• SiparisOlustur -> Telafisi: SiparişiIptalEt

• StokRezerveEt -> Telafisi: StokRezervasyonunuKaldir (ERP'ye iade işlemi)

• OdemeAl -> Telafisi: UcretiIadeEt

Ödeme servisi hata fırlattığında, sistem geriye doğru tetiklenir: Önce ERP servisine StokRezervasyonunuKaldir komutu gider, ardından Sipariş servisine SiparişiIptalEt komutu gider. Böylece sistem Nihai Tutarlılık (Eventual Consistency) noktasına geri döner.

Saga'yı Yönetme Stratejileri

Saga işlemlerini koordine etmenin iki temel mimari yaklaşımı vardır:

1. Koreografi (Choreography - Olay Bazlı)

Merkezi bir yönetici yoktur. Her servis işini bitirince Message Broker'a (Kafka/RabbitMQ) bir event fırlatır. Diğer servis bu event'i dinler ve kendi işini yapar.

• Artısı: Merkezi bir darboğaz (Single Point of Failure) yoktur.

• Eksisi: İşlem adımları arttıkça (örneğin 5-6 adımlı bir süreç), kimin hangi event'i beklediğini takip etmek imkansızlaşır. Sistem bir "Event Spagettisi"ne dönüşebilir.

2. Orkestrasyon (Orchestration - Komut Bazlı)

Süreci baştan sona yöneten merkezi bir "Orkestratör Servis" (Saga State Machine) bulunur. Orkestratör, hangi servisin hangi sırayla çağrılacağını bilir.

• Avantajı: Karmaşık ERP ve iş akışlarında kontrolün tek bir merkezde olması debug (hata ayıklama) süreçlerini inanılmaz kolaylaştırır. Hangi adımda kalındığı state machine üzerinden anlık görülür.

• Örnek Araçlar: Temporal, AWS Step Functions, Camunda veya koda gömülü State Machine kütüphaneleri (örneğin .NET için MassTransit Saga, Java için Axon).

Mimari Uyarılar ve En İyi Pratikler

1. Idempotency (Tekrarlanabilirlik) Şarttır: Telafi işlemleri (örneğin ERP'ye stok iadesi), ağ hataları nedeniyle birden fazla kez tetiklenebilir. Servisleriniz aynı iade talebi 5 kez gelse bile işlemi sadece 1 kez yapacak şekilde (Idempotent) tasarlanmalıdır.

2. Okuma Gecikmeleri (Stale Data): Saga devam ederken, başka bir kullanıcı sistemi sorguladığında siparişi "Beklemede", stoku ise "Düşülmüş" olarak görebilir. İş birimlerinin bu "geçici durumları" tolere edebilecek şekilde iş süreçlerini (Business Logic) tasarlaması gerekir.

Sonuç: Saga deseni, mikroservislerin ve ara katman yazılımlarının özgürlüğünün bedelidir. Uygulaması zor, test etmesi meşakkatlidir; ancak farklı veritabanlarını ve eski (legacy) ERP sistemlerini birbiriyle tutarlı bir şekilde konuşturmanın en güvenilir, kurumsal ve ölçeklenebilir yoludur.