1. GİRİŞ

Dağıtık uygulamalar ve mikroservis mimarileri yaygınlaştıkça, işlemsel bütünlüğü (transactional integrity) sağlama gereksinimi de karmaşıklaştı. Tek bir veritabanı içinde çalışan ACID transaction'lar artık birçok senaryoda yeterli değil: veriler farklı servislerde, farklı veri mağazalarında ve farklı coğrafi bölgelerde tutuluyor. "Distributed transactions" (dağıtık işlemler) bu ihtiyaçla ortaya çıkan bir konudur ve doğru uygulanmadığında veri tutarsızlıklarına, performans düşüşlerine ve operasyonel karmaşıklığa yol açabilir.

Bu konu neden bugün önemli?

• Mikroservis mimarilerinin yaygınlaşması: Bounded context'ler veri sahipliğini dağıttı; tek bir transaction sınırı çoğu zaman yetersiz.
• Global ve geo‑distributed uygulamalar: Farklı bölgelerdeki veri merkezleri arasında koordinasyon gerektiren işlemler arttı.
• İş süreçleri karmaşıklaştı: Bir ödeme, sipariş, envanter ve teslimat iş akışı birçok bağımsız servisi içeriyor; hepsinin tutarlı olması gerekir.

Kimler için önemli?

• Çözüm mimarları ve yazılım mimarları
• Backend geliştiriciler ve veri mühendisleri
• SRE ve platform mühendisleri
• Ürün sahipleri ve teknik liderler — işlem garantileri iş gereksinimleriyle doğrudan ilgilidir

Hangi problemleri çözüyor?

• Birden fazla serviste tutarlı değişiklikler uygulama
• Dağıtık hatalarda veri bütünlüğünü koruma
• İş süreçlerinde geri alma (compensation) ve hata senaryoları tasarlama

2. KAVRAMSAL TEMELLER

Dağıtık transaction'ları anlamak için bazı temel kavramları ve terminolojiyi netleştirmek gerekiyor. Bu temel kavramlar mimari seçimleri ve trade‑off'ları belirleyecektir.

2.1. Temel Tanımlar

• ACID: Atomicity, Consistency, Isolation, Durability — tek bir veritabanı içinde transaction bütünlüğünü tanımlar.
• Distributed Transaction: Birden çok bağımsız veri mağazası veya servis üzerinde eş zamanlı olarak gerçekleştirilen işlemler bütünü; amaç tüm adımların ya beraber tamamlanması ya beraber geri alınmasıdır.
• Two‑Phase Commit (2PC): Klasik coordinator-based protokol; prepare ve commit/abort aşamalarından oluşur. Güvenilir ama bloklayıcıdır.
• Saga Pattern: Mikroservislerde yaygın kullanılan desendir; her adım lokal transaction olarak uygulanır ve başarısızlık durumunda compensation (geri alma) adımları tetiklenir.
• Idempotency: Aynı operasyonun tekrar tekrar uygulanmasının etkisini tek uygulama ile eşdeğer kılma yeteneği; dağıtık retry senaryolarında kritik.
• Eventual Consistency: Dağıtık ortamlarda verilerin zaman içinde tutarlı hale gelmesi beklentisi; çoğu dağıtık pattern'de kabul edilir.
• Coordination Service: Leader election, distributed locks veya metadata için etcd, ZooKeeper, Consul gibi araçlar kullanılır.

2.2. Temel Bileşenler ve Rolleri

• Transaction Coordinator: 2PC veya benzeri protokollerde commit/abort kararını alır.
• Participants / Resources: Transaction'ın etkileşime geçtiği servisler veya veri mağazaları.
• Message Broker: Asenkron iletişim, event publication veya saga orchestration için (Kafka, RabbitMQ, NATS).
• Compensation Handlers: Saga'larda başarısızlık durumunda rollback yerine uygulama mantığına özel düzeltme adımlarını yürüten bileşenler.

3. NASIL ÇALIŞIR?

Burada dağıtık transaction çözümlerinin teknik mimarisini, veri akışını ve en yaygın desenlerin nasıl çalıştığını açıklayacağız.

3.1. Two‑Phase Commit (2PC)

2PC klasik olarak şu iki aşamadan oluşur:

1. Prepare (vazgeçme öncesi): Coordinator, tüm katılımcılara "hazır mısınız?" mesajı gönderir. Katılımcılar, lokal transaction'ı uygulayıp (ör. gerekli değişiklikleri loglayıp) "hazırım" cevabı dönerler veya hata durumunda "hazır değil" derler.
2. Commit / Abort: Tüm katılımcılar "hazırım" dediğinde coordinator commit kararı gönderir; aksi halde abort gönderir. Commit sonrası katılımcılar değişiklikleri kalıcı hale getirir.

Avantajı: ACID benzeri strong guarantees sunar. Dezavantajı: Coordinator veya participant failure durumlarında bloklama (blocking) ve performans maliyeti. Ayrıca coğrafi dağıtımda yüksek latency'ye duyarlı.

3.2. Saga Pattern — Choreography ve Orchestration

Saga, uzun süreli işi bir dizi lokal transaction'a böler. Her adım ya başarılı şekilde uygulanır ya da bir prior adımın compensation action'ı çalıştırılarak sistem tutarlı hale getirilir. Saga iki ana tarzda uygulanır:

• Choreography: Her servis, kendi event'ini yayınlar; diğer servisler bu event'leri dinleyip gerekli işlemi yapar. Merkezi bir orkestratör yoktur. Daha gevşek bağlılık ancak karmaşık hata senaryoları yönetimi olabilir.
• Orchestration: Merkezi bir saga orchestrator (ör. durable workflow engine) adımları sıralar ve her bir adıma komut gönderir. Daha iyi gözlemlenebilirlik ve hata yönetimi sağlar ama orchestrator tek sorumluluk noktasıdır.

Saga'ların en büyük avantajı blocklama olmaması ve dağıtık ortamlara uygunluğu; dezavantajı ise compensation logic'in uygulama domain'ine özgü, karmaşık ve test edilmesi zor olmasıdır.

3.3. Distributed Transactions with Message‑Driven Systems

Mesaj odaklı mimarilerde transactional guarantee'lar, mesajın en az bir defa teslimi (at-least-once) ile sağlanabilir. Pattern'ler:

• Outbox Pattern: Lokal transaction içinde yapılan değişiklikler bir outbox tablosuna yazılır ve daha sonra ayrı process tarafından reliable bir şekilde mesaj broker'a gönderilir. Böylece veri ve mesaj atomikliği korunmaya çalışılır.
• Inbox/Idempotency: Consumer tarafında gelen mesajlara idempotent davranış sağlayarak duplicate mesajların etkisini engellemek gerekir.

3.4. Distributed Coordination ve Consensus

Zaman zaman global kararlar (ör. leader election, global sequence) gerekir. Bu amaçla Raft veya Paxos temelli koordinasyon ve consensus protokolleri kullanılır. Ancak bu protokoller maliyetli olabilir ve sadece gerektiğinde tercih edilmelidir.

3.5. Idempotency, Retries ve Error Handling

Dağıtık transaction'larda ağ hataları, duplicate delivery ve partial failure sık görülür. İyi tasarım şu öğeleri içerir:

• Her işlem idempotent olmalı veya idempotency token'ları kullanılmalı.
• Retry politikaları exponential backoff ve circuit breaker ile kombinlenmeli.
• Monitoring, tracing ve dead-letter queue'lar ile hatalar ayrıştırılmalı ve insan müdahalesine uygun şekilde raporlanmalı.

4. GERÇEK DÜNYA KULLANIMLARI

Büyük ölçekli şirketler dağıtık transaction ihtiyaçlarını farklı yaklaşımlarla çözüyor. Aşağıdaki özetler pratikte hangi desenin hangi ihtiyaçlara cevap verdiğini gösterir.

Netflix

Netflix geniş microservice ekosisteminde saga‑like pattern'leri ve event-driven choreography'i tercih ediyor. Kullanıcı tercihlerinde eventual consistency geniş kabul gördüğü için compensation ve idempotency ön planda.

Uber

Dispatch işlemlerinin hassasiyeti nedeniyle Uber, locality ve strong consistency gereksinimlerini dikkatle dengeler; bazı kritik path'lerde koordinasyon ve idempotency ile tutarlılık sağlanır.

Amazon (AWS)

AWS hizmetleri (SQS, SNS, DynamoDB, Step Functions) ile orchestration, outbox pattern ve durable workflows (Step Functions) sunarak dağıtık işlemleri yönetir. Örneğin Step Functions ile long‑running stateful workflow'lar orchestration şeklinde modellenir.

Stripe

Ödeme işlemlerinde strong consistency, idempotency ve auditability en kritik gereksinimlerdir. Stripe gibi ödeme sistemleri, transactional all‑or‑nothing garantilerini sağlamak için domain‑level mekanizmalar ve sıkı operasyonel prosedürler uygular.

OpenAI

Billing, subscription ve prompt/fine‑tuning pipeline'ları gibi kritik path'lerde güçlü guarantees gerekir; model training ve telemetry pipeline'larında event-driven eventual consistency kabul edilebilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Saga ve message‑driven yaklaşımlar yüksek availability ve partition tolerance sağlar.
• 2PC benzeri protokoller güçlü consistency sağlar; kritik finansal işlemler için uygundur.
• Outbox ve idempotency pattern'leri veri ve mesaj atomikliği sağlama çabalarında pragmatik çözümler sunar.

Sınırlamalar

• 2PC bloklayıcı olabilir ve performans maliyeti yüksektir; coğrafi dağıtımda latency daha da artar.
• Saga'lar compensation logic gerektirir; bunların doğru tasarlanması zor ve hata‑eğilimlidir.
• Mesaj tabanlı çözümler duplicate delivery ve ordering sorunları gibi yeni sınıflar hatalar getirir; idempotency yönetimi meşakkatlidir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo yaygın pattern'leri karşılaştırır: 2PC, Saga, Outbox ve Distributed SQL gibi yaklaşımlar uygulama ihtiyaçlarına göre seçilir.

7. EN İYİ PRATİKLER

Dağıtık transaction tasarımında üretim ortamında güvenilirliği, gözlemlenebilirliği ve operasyonel sürdürülebilirliği sağlamak için önerilen pratikler:

Production Kullanımı

• Transaction boundary'lerini mümkün olduğunca küçük tutun; bounded contexts içinde lokal transaction'ları tercih edin.
• Veri sınıflandırması yapın: hangi veriler strong atomicity gerektiriyor, hangileri eventual consistency ile yönetilebilir?
• Orchestration yerine choreography basit senaryolarda tercih edilebilir; kompleks iş akışlarında orchestrator ile tutarlılık ve gözlemlenebilirlik artırılabilir.

Performans Optimizasyonu

• 2PC gibi synchronous protokoller gereken durumlar dışında avoid edilmelidir; düşük latency path'leri için alternative desenler düşünün.
• Outbox pattern ile mesaj publish atomikliğini sağlayın; message batching ve compression ile performansı iyileştirin.
• Idempotency token'ları, deduplication ve consumer side checks ile duplicate delivery etkilerini minimize edin.

Güvenlik

• Transaction koordinatörleri ve orkestratörler yetkilendirme ve erişim kontrolü altında olmalı; kimlik doğrulama ve audit logging zorunlu.
• Mesaj kanalları TLS/mTLS ile korunmalı ve sensitive data masking/PII politikalarına uyum sağlanmalı.

Ölçeklenebilirlik ve Operasyon

• Saga orchestrator'larını ve mesaj broker'ları izleyin: workflow length, failure rate, compensation count gibi metrikler toplayın.
• Outbox cleanup, tombstone, snapshot ve retention politikalarını otomatikleştirin.
• Failover playbook'ları, DR tatbikatları ve chaos engineering ile gerçek dünya senaryolarını test edin.

8. SIK YAPILAN HATALAR

• Dağıtık transaction ihtiyacını aceleyle 2PC ile çözmek: Daha hafif ve servis dostu desenler çoğu durumda yeterlidir.
• Compensation logic'i ihmal etmek: Saga uygulamalarında rollback yerine compensation kodunu planlamamak veri bozulmasına yol açar.
• Idempotency'e önem vermemek: Retry ve duplicate mesajlar sistemde hatalara yol açar.
• Monitoring ve tracing olmadan dağıtık workflow'ları işletmek: root cause analysis ve SLA yönetimi zorlaşır.
• Transactional scope'u çok geniş tutmak: performans düşer, lock contention artar.

9. GELECEK TRENDLER

AI‑Assisted Workflow Tuning

ML teknikleri workflow performansını izleyerek, compensation tetikleme koşullarını iyileştirecek ve otomatik tuning önerileri sunacaktır. Bu, özellikle geniş çaplı saga orchestrator'larında operasyon yükünü azaltabilir.

Serverless Durable Workflows

Serverless platformların durable workflow hizmetleri (ör. AWS Step Functions, Azure Durable Functions) daha fazla benimseniyor; bu sayede stateful orchestration yönetimi servis sağlayıcı tarafından sunuluyor ve geliştiriciler daha az infra yönetiyor.

Transactional Guarantees at Scale

Distributed SQL veritabanları ve global transactional hizmetler gelişmeye devam edecek; ancak maliyet ve latency trade‑off'ları her zaman var olacaktır. Uygulama mimarileri bu servislerle daha sık entegre olacak.