1. GİRİŞ

Verinin tutarlılığı (data consistency), dağıtık ve merkezi uygulamalarda güvenilir davranışın temel şartıdır. Uygulamalar büyüdükçe ve coğrafi olarak dağıldıkça, verinin hangi noktada ve hangi koşullarda "doğru" sayılacağı belirsizleşir. Bu nedenle tutarlılık modelleri, uygulama gereksinimlerine göre bilinçli olarak seçilmeli ve mimariye entegre edilmelidir.

Bu konu neden bugün önemli?

Bulut, mikroservisler, veri-yoğun AI uygulamaları ve global kullanıcı tabanları veri akışını karmaşıklaştırdı. Aynı zamanda kullanıcı beklentileri ve uyumluluk gereksinimleri (ör. finansal işlemler, sağlık verileri) verinin doğru bir şekilde korunmasını zorunlu kılıyor. Tutarlılık kararları doğrudan kullanıcı deneyimi, veri kaybı riski ve operasyonel karmaşıklık üzerinde etkili.

Kimler için önemli?

• Veri mimarları ve çözüm mimarları
• SRE (Site Reliability Engineering) ve platform mühendisleri
• Backend geliştiriciler ve ürün sahipleri
• Güvenlik ve uyumluluk ekipleri

Hangi problemleri çözüyor?

• Veri tutarsızlıklarından kaynaklanan hataları ve kullanıcı deneyimi bozulmalarını önleme
• RPO/RTO ve iş gereksinimlerine uygun durability sağlama
• Dağıtık sistemlerde tutarlılık–kullanılabilirlik–partition tolerance trade‑off'larını yönetme

2. KAVRAMSAL TEMELLER

Tutarlılığı tartışmadan önce temel kavram ve terminolojiyi netleştirelim. Bunlar mimari kararlarınızı konuşurken ortak dil olacaktır.

2.1. Temel Tanımlar

• Consistency (Tutarlılık): Bir sistemi okuyan tüm kullanıcıların aynı veriyi görme beklentisidir. Ancak "aynı"nın ne zaman geçerli olduğu modeli seçime bağlıdır.
• Strong consistency: Bir yazma işlemi tamamlandıktan sonra tüm okuma işlemleri hemen bu yazmayı görür. Kullanıcılar her zaman aynı veriyi görür.
• Eventual consistency: Bir yazma işlemi sonrası sistem sonunda tutarlı hale gelir; kısa dönemli gecikmeler veya stale reads kabul edilebilir.
• Read-after-write consistency: Bir kullanıcı yazma yaptıktan hemen sonra yaptığı okumalarda yazılan değeri görmelidir.
• Linearizability: Gerçek zamanlı tek bir küresel sıra üzerinde tüm işlemler çalışmış gibi görünür; güçlü bir correctness garantisidir.
• Serializability: Transaction seviyesinde, paralel çalışan transaction'ların bir seri halde çalışmış gibi davranmasıdır; en güçlü isolation seviyelerindendir.
• CAP Theorem: Bir dağıtık sistem aynı anda Consistency, Availability ve Partition tolerance'ın hepsini sağlayamaz; partition oluştuğunda C veya A'dan birini feda etmelisiniz.
• CRDT (Conflict-free Replicated Data Type): Çakışmasız çoğaltma için tasarlanmış veri yapıları; offline veya çoklu yazma ortamlarında otomatik birleşme sağlar.

2.2. Tutarlılık Türleri (Kısa Özet)

• Strong / Linearizable: En katı model; genelde leader-election ve synchronous replication ile sağlanır.
• Sequential: Her işlem global bir sıraya göre düzenlenir ama gerçek zamanlı ordering zorunlu değildir.
• Eventual: Sistemin yeterli süre verildiğinde tutarlı olacağı söylenir; web cache'ler ve bazı NoSQL senaryolarında yaygındır.
• Session consistency: Bir session içinde kullanıcı kendi yazdıklarını görür; multi-session için garanti yoktur.
• Monotonic reads / Writes: Monotonic reads, bir client asla daha eski bir versiyonu görmez; monotonic writes, bir client'ın yazıları sırayla uygulanır.

3. NASIL ÇALIŞIR?

Tutarlılık modelleri ve mekanizmaları nasıl uygulanır? Bu bölümde teknik mimari, veri akışı ve uygulama düzeyinde alınacak kararları detaylandırıyoruz.

Sistem Mimarisi ve Replication Modelleri

• Primary–Replica (Leader‑Follower): Yazma genellikle tek lidere gider; synchronous replication ile strong consistency sağlanabilir, async ile latency düşerken veri kaybı riski artar.
• Multi‑Leader: Birden fazla yazma noktası; geo‑distributed yazmalar için uygun ancak conflict resolution gerekir.
• Leaderless (Quorum‑based): Her düğüm yazılabilir; quorum parametreleri (R, W, N) ile consistency/availability dengesi ayarlanır (örn. Cassandra, Dynamo).

Commit ve Acknowledgement Stratejileri

Yazma işlemlerinin kabul edilme kriterleri tutarlılığı etkiler:

• Write Ack = majority: Majority ack alındıktan sonra commit; partition durumunda availability etkilenebilir.
• Sync vs Async: Sync commit, primarlarda ve replikalarda anlık persist sağlar; async commit, düşük latency ama potansiyel veri kaybı riski sunar.

Transaction Modelleri ve Dağıtık Transaction'lar

ACID transactional garantileri dağıtık sistemlerde pahalıdır. Yöntemler:

• Two‑Phase Commit (2PC): Güvenilir ama bloklayıcı; coordinator failure senaryoları karmaşıktır.
• Saga Pattern: Uzun süreli iş akışları için local transaction'lar ve compensation (geri alma) adımları kullanılır; eventual consistency ile uyumludur.
• Idempotency ve deduplication: Multi‑attempt durumlarında tekrar eden yazmaları güvenle işlemek için kullanılmalıdır.

Conflict Detection ve Resolution Stratejileri

• Last-write-wins (LWW): Basit ve deterministik fakat semantik anlamda veri kaybına neden olabilir.
• Merge functions / CRDT: Verinin semantik birleşimini sağlayan fonksiyonlar; offline ve concurrent yazma durumları için idealdir.
• Application-level reconciliation: İş mantığına özgü çözüm; genelde domain bilinci gerektirir ama en doğru sonuçları verir.

Consistency Patterns ve Pragmatik Seçimler

Gerçek dünya uygulamalarında genelde hibrit yaklaşımlar benimsenir:

• Critical data → Strong consistency: Finansal işlemler, kimlik doğrulama, ödeme onayları.
• Non-critical / high‑throughput → Eventual: Analytics events, telemetri, bazı kullanıcı etkinlikleri.
• Session consistency: Kullanıcı deneyimi için yeterliyse, kullanıcı kendi session'u içinde yazdıklarını hemen görmelidir.

4. GERÇEK DÜNYA KULLANIMLARI

Farklı sektör ve şirketlerin tutarlılık tercihleri ve uygulama örnekleri, kararların pratikte nasıl alındığını gösterir.

Netflix

Kullanıcı tercihlerinde eventual consistency kabul edilebilir; ancak ödeme veya abonelik gibi kritik işlemler strong consistency ile korunur. Cache hiyerarşileri ve eventual replication kombinasyonu kullanılır.

Stripe

Ödeme işlemlerinde strong consistency ve idempotency birincildir. Transactional integrity, audit ve uyumluluk gereksinimleri nedeniyle ACID‑like garantiler tercih edilir.

Amazon (AWS)

DynamoDB, farklı consistency seçenekleri (strong veya eventual) sunar; tasarımcıya kontrol bırakır. S3 read-after-write consistency kademeli evrilmiş ve belirli pattern'ler için garanti sağlar.

OpenAI

Model metadata ve prompt history bazı durumlarda eventual consistency ile yönetilirken, fatura ve abonelik verileri strong consistency ile saklanır. Model training verileri için append‑only ve immutable storage tercih edilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Doğru tutarlılık seçimi performans ve kullanılabilirlik arasında uygun denge sağlar.
• Hibrit modeller maliyetleri ve gecikmeyi optimize ederken kritik veri güvenliğini korur.
• CRDT ve uygulama seviyesinde reconciliation offline-first ve edge senaryolarını mümkün kılar.

Sınırlamalar

• Strong consistency performans maliyeti getirir; global dağıtımlarda yüksek latency oluşabilir.
• Eventual consistency uygulama karmaşıklığını artırır; hata durumlarında veri korelasyonu zorlaşır.
• Distributed transactions operational complexity ve hata yüzdesini artırır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo yaygın tutarlılık yaklaşımlarını, avantaj ve dezavantajlarıyla karşılaştırır.

7. EN İYİ PRATİKLER

Tutarlılık kararları uygulama risklerini azaltmak ve operasyonu kolaylaştırmak için aşağıdaki pratikleri öneriyoruz. Kod örneği yoktur; mimari ve operasyonel tavsiyelere odaklanılmıştır.

Production Kullanımı

• Veri sınıflandırması yapın: hangi veriler critical, hangi veriler eventual consistency ile yönetilebilir netleştirin.
• SLO'ları consistency gereksinimleriyle hizalayın: read-after-write beklentileri SLO'lara konmalı.
• Failover ve partition senaryoları için önceden belirlenmiş politikalarınız olsun; canary ve DR tatbikatları yapın.

Performans Optimizasyonu

• Critical path'lerde sync replication ve write quorum kullanırken, analytics/telemetry pipeline'larında async tercih edin.
• Read routing: son yazılan veriyi görmek isteyenler primary üzerinden yönlendirilsin; stale okuma toleransı varsa replica üzerinden yük dağıtın.
• Idempotency ve deduplication ile multi‑attempt edge case'lerini güvenle yönetin.

Güvenlik

• Replication trafiği ve snapshot'lar TLS/mTLS ile korunmalı, erişim kontrolleri kata uygulanmalıdır.
• Veri kurtarma ve replay işlemleri sırasında veri sızıntısı riskine karşı masking ve audit logging gereklidir.

Operasyon ve İzleme

• Replication lag, commit latency, WAL position, apply errors gibi metrikleri per-replica izleyin.
• Conflict rate ve reconciliation metrics toplayın; CRDT veya uygulama seviyesinde reconciliation takibini sağlayın.
• Change Data Capture (CDC) pipeline'larını ve backfill süreçlerini testli otomasyon ile yönetin.

8. SIK YAPILAN HATALAR

• Tutarlılık gereksinimini yanlış sınıflandırmak: kritik veriler eventual modelle korunursa iş kaybı veya uyumsuzluk oluşur.
• Quorum parametrelerini varsayılan bırakmak: yanlış R/W/N kombinasyonu veri kaybına veya performans bozulmasına yol açar.
• Conflict resolution planı olmadan multi‑leader kullanmak: veri çakışmaları ve kayıt kayıpları ortaya çıkar.
• Replication lag'ı izlememek: stale reads, yanlış kararlar ve müşteri şikâyetlerine yol açar.
• Transaction sınırlarını geniş tutmak: distributed transaction'larda latency ve failure oranı artar.

9. GELECEK TRENDLER

AI‑Assisted Consistency Tuning

ML modelleri, sistem davranışını izleyip proaktif olarak quorum ayarları, rebalancing zamanlamaları ve replication pipeline parametreleri önerebilecek. Bu, manuel tuning ihtiyacını azaltacaktır.

CRDT ve Offline‑First Uygulamalar

Offline yetenekli uygulamalar ve edge senaryolarında CRDT'lerin kullanımı artacak; uygulama mantığını basitleştirirken conflict yönetimi otomatikleşecek.

Distributed SQL ve Global Tutarlılık

Distributed SQL platformları (Spanner, CockroachDB, Yugabyte) strong consistency ve düşük gecikme arasında daha iyi trade‑off'lar sunmaya devam edecek; geliştirici deneyimini iyileştirecek.