Dağıtık Veri Tutarlılığı: Saga Deseni ve Eventual Consistency

Dağıtık sistemde 'işlem' nereye gitti?

Sınırın ötesine geçemedi: tek veritabanının ACID işlemi, servis/shard sınırını aşamaz — ve bunu aşmaya çalışan dağıtık kilitli protokoller, yüksek trafikte kullanılabilirliği rehin alır. Modern cevap, uzun işlemi yerel adımlara bölüp hataları telafiyle yönetmektir: saga deseni. Bu yazı saga'nın iki biçimini, telafi tasarımını ve nihai tutarlılığın kullanıcıya nasıl anlatılacağını kurar.

Saga: yerel işlemler + telafi zinciri

Saga, çok servisli bir iş akışını (sipariş ver → stok rezerve et → tahsilat yap → kargo planla) her biri kendi servisinde yerel işlem olan adımlara böler. Bir adım başarısız olursa geri alma, veritabanı rollback'i ile değil telafi işlemleriyle (compensation) yapılır: tahsilat başarısızsa rezervasyon serbest bırakılır, sipariş iptal edilir. İki temel biçimi vardır ve seçim mimari karakteri belirler.

Orkestrasyon mu, koreografi mi?

Pratik kural: sipariş/ödeme gibi omurga akışlarda orkestrasyon (durumu sorgulanabilir bir saga kaydıyla), bildirim/sadakat gibi yan etkilerde koreografi. Orkestratör bir 'dağıtık monolit beyni'ne dönüşmesin diye iş kuralı taşımaz — yalnızca akışı yönetir; kurallar servislerde kalır.

Telafi tasarımı: geri alınamazı sona koy

Telafi, matematiksel tersine çevirme değildir — 'e-posta gönderildi' geri alınamaz, 'tahsilat' ancak iadeyle telafi edilir. Bu yüzden adım sıralaması bir tasarım kararıdır: geri alınması kolay adımlar öne, geri alınamaz adımlar (para çekimi, dış sisteme bildirim) mümkün olduğunca sona. Ek disiplinler: her adım ve telafisi idempotent olmalı (saga yeniden denediğinde çift etki yok — asenkron yazımızın kuralı burada da geçerli); telafinin kendisi de başarısız olabilir, bu yüzden telafi kuyruğu + alarm + manuel müdahale defteri gerekir; ve her saga'nın bir zaman aşımı vardır — sonsuza kadar 'yarım' kalmış akış, envanter kilitleyen hayalettir.

Eventual consistency: pencereyi kullanıcıya tasarlamak

Adımlar asenkron aktığı için sistemin bütünü anlık tutarlı değildir — ve bunun kullanıcıya görünen yüzü, mühendisliğin değil deneyim tasarımının konusudur. İşleyen desenler: durum şeffaflığı ('siparişiniz alındı, ödeme onayı bekleniyor' — adımlar görünür, belirsizlik yok); iyimser onay + nazik geri dönüş (sipariş anında kabul edilir; nadir başarısızlıkta özürlü bildirim + otomatik iade — kampanya ölçeğinde saniyeler kazandırır); read-your-writes koruması (kullanıcının kendi eylemi kendi ekranında anında görünür — veritabanı yazımızdaki birincilden okuma kuralı); ve yalancı negatiften kaçınma ('bulunamadı' demeden önce yayılım penceresini bekleyen tasarım). Tutarlılık penceresinin süresi ölçülür ve ürün ekibiyle paylaşılır — 'ne kadar gecikebilir?' sorusunun cevabı tahmin değil metrik olmalıdır.

Uzlaştırma: nihai tutarlılığın sigortası

Olay kaçar, telafi düşer, entegrasyon çift kayıt üretir — dağıtık gerçeklik budur. Sigorta, ERP entegrasyon yazımızdan tanıdık disiplindir: periyodik uzlaştırma — sistemler arası kayıt sayımı ve örneklem karşılaştırması, farkların otomatik raporu ve düzeltme prosedürü. Saga kayıtları burada altın kaynaktır: 'başlamış ama bitmemiş' akışların listesi, uzlaştırmanın ilk sorgusudur. Finansal akışlarda bu rapor günlük; diğerlerinde haftalık ritim pratik dengedir.

İş etkisi: tutarlılık modeli bir ürün kararıdır

Güçlü tutarlılık ısrarı dağıtık sistemde ya ölçeği ya kullanılabilirliği kurban eder; kontrolsüz gevşeklik ise çift tahsilat ve kayıp siparişle güveni yıkar. Doğru nokta iş akışı bazında seçilir: para hareketi 'kesin ve izlenebilir', bildirimler 'eninde sonunda' olabilir. Bu seçimin belgelenmiş olması — hangi akış hangi garantiyle çalışır — hem mühendisliğe hem müşteri iletişimine netlik verir: kampanya günü 'ödemem geçti mi?' sorusuna sistemin cevabı vardır, çünkü saga durumu sorgulanabilirdir.

Sık sorulan sorular

İki aşamalı commit (2PC) neden tercih edilmiyor?

Koordinatör arızasında kilitli kalan kaynaklar ve tüm katılımcıların eşzamanlı sağlığına bağımlılık, yüksek trafikle uyumsuzdur. Servisler arası pratik standart saga + telafidir; 2PC istisnai, kontrollü iç senaryolara kalır.

Saga durumunu nerede tutmalıyım?

Orkestrasyonda saga yöneticisinin kendi tablosunda (adım, durum, deneme, son hata); koreografide her servisin işlenmiş olay kaydında + uçtan uca korelasyon kimliğinde. Her iki modelde de 'bu akış nerede?' sorgusu tek sorguyla cevaplanabilmelidir.

Outbox ile saga ilişkisi ne?

Outbox, tek servisin 'yaz + yayınla' atomikliğini sağlar; saga, çok servisin akış bütünlüğünü yönetir. Saga adımlarının olayları outbox'la yayınlanır — ikisi rakip değil, katmandır.

Test nasıl yapılır?

Adım ve telafilerin sözleşme testleri + saga akışının hata enjeksiyonlu entegrasyon testleri ('3. adım düşerse ne olur?') + kaos tatbikatı. Telafi yolu, üretimde ilk kez çalışmamalıdır.

Dağıtık tutarlılık kontrol listesi

1. Akış bazında tutarlılık gereksinimi (kesin/nihai) yazılı

2. Omurga akışlar orkestrasyonlu saga; durum sorgulanabilir

3. Adım sırası: geri alınamazlar sona; tüm adım+telafiler idempotent

4. Telafi hatası kuyruğu, alarmı ve müdahale defteri mevcut

5. Tutarlılık penceresi ölçülüyor; UX durum şeffaflığıyla tasarlı

6. Read-your-writes kritik ekranlarda korunuyor

7. Periyodik uzlaştırma raporu ve yarım-akış sorgusu çalışıyor

SSH Yazılım, dağıtık iş akışlarının saga tasarımını ve tutarlılık mimarisini uçtan uca kurar. Akış bütünlüğünüzü birlikte güvenceye alalım.