Dağıtık sistemde Saga Pattern ile eventual consistency'i nasıl tasarlarım?

Kısa cevap: 2PC’den kaçınman doğru — o kilitlenir ve ölçeklenmez. Saga, tek bir atomik işlemi, her birinin bir telafi aksiyonu olduğu yerel işlemler dizisine çevirir. Senin akışın için orchestrator tabanlı Saga doğru tercih.

Asıl mesele şu: artık her şeyi tek transaction içinde geri alamazsın. Bunun yerine, “bir adım bozulursa, daha önce yapılan adımları telafi et” disiplinini kurman lazım.

1. Merkezi koordinatör adımları kuyruktan sürsün. Orchestrator (Sipariş Servisi) komutları kuyruğa basar: ödemeyi rezerve et → stok düş → gönderi oluştur. Her servis işini bitirince sonucu geri bildirir, koordinatör bir sonraki adıma geçer. Akış tek bir yerde, açık ve okunabilir.
2. Hata olunca telafileri ters sırayla çalıştır. Kargo adımı patlarsa orchestrator geriye doğru gider: stoğu geri artır, ödemeyi iade et. Telafi işlemleri “geri alma” değil, ileri yönde dengeleyici işlemlerdir — iade gerçek bir işlemdir, sihirli bir rollback değil.
3. Her adımı idempotent yap. Kuyruklarda retry garantilidir; aynı “stok düş” komutu iki kez gelebilir. Her komuta deterministik bir saga_id + step_id koy, işlenmişse tekrar işleme. Idempotency olmadan saga ikinci denemede çift iade/çift stok üretir.
4. Outbox pattern ile atomikliği koru. “Yerel işi yap + sonraki olayı yayınla” ikilisi tek transaction’da olmalı. İşi ve olayı aynı DB’deki outbox tablosuna yaz, ayrı bir relay kuyruğa taşısın. Yoksa iş commit olur ama olay yayınlanmazsa saga ortada kalır.
5. Saga durumunu kalıcı tut. Hangi adımdasın, hangileri tamamlandı — bunu bir tabloda sakla ki koordinatör çökse bile yeniden ayağa kalktığında kaldığı yerden devam etsin.

Sonuç: Orchestration’ı choreography’e tercih et; akış açık ve telafi sıralaması net. Eventual consistency’i kabul et: stok birkaç saniye tutarsız görünebilir, sonra mutabık olur. Mimari kararı sade.dev’de, kuyruk mekaniğini hub’daki yazıda derinleştiriyorum.