Mikroservislerde dağıtık transaction nasıl yönetilir? 2PC ve Saga pattern'i karşılaştırın.

Her servisin kendi veritabanı olduğunda, birden fazla servise yayılan bir işlemi (sipariş oluştur, ödeme al, stok düş) tek bir ACID transaction ile yapamazsınız. İki temel yaklaşım vardır.

Two-Phase Commit (2PC)

Bir koordinatör tüm katılımcılara önce "hazır mısın?" (prepare) sorar; hepsi evet derse "commit", biri hayır derse "rollback" gönderir.

• Artı: güçlü tutarlılık (atomiklik).
• Eksi: katılımcılar karar gelene kadar kilitleri tutar; koordinatör çökerse sistem bloklanır; gecikme ve erişilebilirlik kötüleşir. Kafka, çoğu NoSQL ve dış API'ler 2PC desteklemez.
• Sonuç: mikroservislerde nadiren kullanılır.

Saga pattern

Büyük işlem, her biri kendi lokal transaction'ı olan adımlara bölünür. Bir adım başarısız olursa önceki adımların etkisini geri alan telafi edici işlemler (compensating transactions) çalıştırılır.

1. Order Service    : siparişi PENDING oluştur     | telafi: siparişi CANCELLED yap
2. Payment Service  : ödemeyi al                   | telafi: iade et
3. Inventory Service: stok düş  -> BAŞARISIZ
   => Payment iade edilir, Order CANCELLED olur

İki koordinasyon şekli:

Orchestration için Temporal, Camunda, AWS Step Functions gibi araçlar kullanılır.

Saga'nın zorlukları

• İzolasyon yoktur: ara durumlar diğer işlemler tarafından görülebilir (ör. ödeme alındı ama sipariş henüz onaylanmadı). Çözüm: PENDING gibi semantik kilit durumları.
• Telafi her zaman tam geri alma değildir: gönderilmiş e-posta geri alınamaz, yerine "iptal bildirimi" gönderilir.
• Her adım ve telafi idempotent olmalı, çünkü mesajlar tekrar gelebilir.
• Olay yayınlama ile DB yazmasının atomik olması için genellikle transactional outbox ile birlikte kullanılır.