1. GİRİŞ

Dağıtık sistemlerde veri tutarlılığı (consistency) uygulama davranışını, kullanıcı deneyimini ve hata senaryolarındaki sonuçları doğrudan etkiler. Bulut tabanlı mimariler, mikroservisler, event‑driven sistemler ve edge computing ile birlikte farklı bileşenler aynı veriye erişirken farklı zamanlarda farklı görünümlerle karşılaşabilir. Bu nedenle "hangi tutarlılık modelini seçmeliyiz?" sorusu yalnızca akademik bir tartışma değil; üretimde karşımıza çıkan performans, kullanılabilirlik ve veri doğruluğu gereksinimlerinin merkezinde yer alır.

Bu konu neden bugün önemli?

• Global dağıtık uygulamalar latency ve partition riskleri nedeniyle farklı tutarlılık garantileri gerektirir.
• Edge computing ve intermittant connectivity (ör. mobil, IoT) senaryoları eventual ve offline‑first modellerini öne çıkarıyor.
• AI/ML pipeline'larında veri kalitesi, eğitim ve inference doğruluğu için tutarlılık gereksinimleri kritik hale geldi.

Kimler için önemli?

• Yazılım mimarları ve veri mühendisleri
• Backend geliştiriciler, platform mühendisleri ve SRE ekipleri
• Ürün sahipleri — kullanıcı deneyimi ve hata toleransı kararlarında etkili

Hangi problemleri çözüyor?

• Farklı kullanıcılar aynı verinin farklı görünümlerini gördüğünde ortaya çıkan mantıksal hataları minimize etme
• Performans ve availability ile veri doğruluğu arasında bilinçli trade‑off sağlama
• Offline çalışma, replikasyon gecikmeleri ve partition senaryoları için uygun davranış belirleme

2. KAVRAMSAL TEMELLER

2.1 Tutarlılık nedir — kısa tanım

Tutarlılık, bir dağıtık sistemde verinin hangi garantilerle okunup yazıldığını tanımlayan bir kavramdır. "Okunan veri en son yazılan değeri gösterir mi?", "iki okuma arasında sıra korunur mu?" gibi sorular tutarlılık modelinin alanına girer. Tutarlılık modelleri farklı derecelerde katılık sağlar: strong (linearisability), causal, eventual gibi modeller uygulamaya göre seçilir.

2.2 Temel terminoloji

• Linearizability (Strong consistency): Her işlem gerçek zamanlı sıralamaya uygun şekilde tek bir küresel sıra içinde yer alır; bir yazma tamamlandıktan sonra tüm sonraki okumalar bu yazmayı görür.
• Sequential consistency: Tüm işlemler bir sıralamaya sahiptir ve her işlem bu sıra ile tutarlı; ancak sıra gerçek zamanla (wall clock) eşlenmeyebilir.
• Causal consistency: Bir işlem başka bir işlemin neden olduğu bir etkiye sahipse (causal relation), bu ilişki korunur. Bağımsız işlemler farklı sıralarda görülebilir.
• Eventual consistency: Bir süre sonra tüm replikaların aynı duruma ulaşacağı garantisi (ancak ne zaman ulaşılacağı belirsizdir).
• Monotonic reads/writes: Okumanın veya yazmanın monoton artması garantileri — ör. bir kullanıcı daha önce gördüğü veriyi tekrar görecektir (monotonic reads).
• Session consistency: Tek bir kullanıcı oturumu boyunca tutarlı görünüm sağlama garantisi.

2.3 Neden farklı modeller var?

Farklı modeller farklı performans/availability/tutarlılık trade‑off'ları sunar. Strong consistency uygulamak genelde daha yüksek gecikme ve düşük availability maliyeti getirir; event‑driven, yüksek throughput ve offline senaryolar eventual consistency ile daha verimli çalışır. Bu nedenle sistem gereksinimleri önceliklendirilmeli ve uygun model seçilmelidir.

3. NASIL ÇALIŞIR? — TEKNİK DETAYLAR VE MODELLER

3.1 Strong consistency (Linearizability)

Linearizability, en sık tartışılan güçlü tutarlılık modelidir. Bir yazma işlemi başarılı olarak geri döndüğünde, o yazmayı takip eden tüm okumalarda yeni değer görünür. Gerçek zamanlı ordering (real‑time order) sağlandığı için programmer açısından en sezgisel modeldir. Ancak global leader seçimi, synchronous replication ve quorum tabanlı commit gereksinimleri nedeniyle gecikme ve availability üzerinde maliyeti yükseltir.

Kullanım senaryoları

• Finansal işlemler ve bakiye hesaplama
• Rezervasyon sistemleri (seat booking) — double booking'i önlemek için

3.2 Sequential consistency

Sequential consistency, işlemlerin bir sıra içinde çalıştığı garantisini verir fakat bu sıra mutlaka gerçek zamanla eşleşmek zorunda değildir. Programcı bakış açısı olarak strong consistency'ye benzer kolaylık sağlar; ancak implementasyon olarak linearizability kadar pahalı olmayabilir. Genelde weaker implementations ile sağlanır.

3.3 Causal consistency

Causal consistency, neden‑sonuç ilişkilerini korur. Eğer A olayı B'yi tetiklemişse (ör. Alice bir yorum yazdı ve Bob bu yoruma cevap verdi), bütün kullanıcılar B'yi görmeden önce A'yı göreceklerdir. Ancak A ve C bağımsızsa farklı sıralarda görülebilirler. Causal consistency, sosyal uygulamalar, collaborative editing ve bazı event‑driven senaryolar için idealdir.

3.4 Eventual consistency

Eventual consistency en gevşek ama en performans‑odaklı yaklaşımdır. Sistem uzun dönemde tutarlı olacak şekilde tasarlanmıştır ancak herhangi bir anlık okuma farklı sonuçlar dönebilir. Conflict resolution (last‑write‑wins, vector clocks, application merge) mekanizmalarına ihtiyaç vardır. Yüksek erişilebilirlik ve düşük gecikme önemliyse tercih edilir.

Conflict resolution yaklaşımları

• Last‑Write‑Wins (LWW) — zaman damgasına göre seçim
• Vector clocks — eşzamanlılık tespiti ve merging
• CRDT (Conflict‑free Replicated Data Types) — otomatik birleşme garantisi
• Application driven reconciliation — domain mantığına uygun merge

3.5 Session, Monotonic ve Prefix konsistensy türleri

• Session consistency: Tek oturum içindeki istekler için tutarlı görünüm sağlar; örn. bir kullanıcı kendi yazdığı yorumu aynı oturumda hemen görür.
• Monotonic reads: Okumalar geriye dönük gitmez; bir kullanıcı daha önce gördüğü veriden daha eski bir versiyonu göremez.
• Monotonic writes: Yazma sırası korunur; bir kullanıcının yazıları sırayla uygulanır.
• Read‑your‑writes: Kullanıcının yaptığı yazmayı takip eden okumalarda bu yazma görülebilir.

3.6 Tunable consistency ve quorum mekanizmaları

Birçok dağıtık veri deposu R/W quorum parametreleri ile "tunable consistency" sunar. Örneğin N replika varsa, W (write quorum) ve R (read quorum) seçimleri ile R + W > N koşulunu sağlayarak read‑after‑write garantisi elde edilebilir. Bu mekanizma, uygulamaya göre performans/tutarlılık dengesini ayarlamayı mümkün kılar.

4. GERÇEK DÜNYA KULLANIMLARI

Finansal sistemler

Bakiye hesaplamaları, transfer işlemleri ve denetim gereksinimleri nedeniyle finans dünyası genelde strong consistency veya transactional guarantees talep eder. Distributed transactions, serializable isolation veya Spanner benzeri global konsensüs çözümleri burada tercih edilir.

Sosyal medya ve collaborative uygulamalar

Yüksek throughput, düşük gecikme ve offline senaryolar sosyal medya uygulamalarında önceliklidir. Bu nedenle causal veya eventual consistency modelleri; CRDT'ler ve merge stratejileri sıkça kullanılır.

IoT ve offline‑first uygulamalar

Cihazların bazen bağlantısız olduğu senaryolarda eventual consistency ve reconciliation stratejileri kaçınılmazdır. Local queues, conflict resolution ve server‑side reconciliation pratikleri uygulamada yaygındır.

E‑ticaret ve rezervasyon

Rezervasyon gibi kritik path'lerde strong veya sequential consistency tercih edilebilir; stok yönetimi ve distributed locking mekanizmaları ile double‑booking engellenir. Ancak katalog ve browse operasyonlarında daha gevşek modellerle hız sağlanabilir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Doğru model seçimi performans, maliyet ve kullanıcı deneyimi arasında denge sağlar.
• Causal ve eventual modeller yüksek erişilebilirlik ve ölçeklenebilirlik sunar.
• Strong modeller kritik verilerde deterministik davranış ve kolay reasoning sağlar.

Sınırlamalar

• Strong consistency düşük latency hedefleriyle çelişebilir ve availability maliyetini artırabilir.
• Eventual consistency uygulama seviyesinde daha fazla karmaşıklık ve test gerektirir.
• Conflict resolution stratejileri yanlış seçildiğinde veri bozulmasına yol açabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Veri kritikliği ile latency hedeflerini ayırın: hangi path'ler strong consistency gerektiriyor?
• Domain driven design ile bounded context'leri tanımlayın; her context için uygun tutarlılık modeli belirleyin.
• Tunable consistency ve quorum parametreleri ile çeşitli senaryolarda davranışı test edin.

Performans optimizasyonu

• Okuma‑yoğun yüklerde read‑replica ve cache (materialized views) kullanın.
• Eventual sistemlerde conflict önleyici tasarım (CRDT, idempotent operations) uygulayın.

Güvenlik

• Tutarlılık modelleri veri gizliliği ve regülasyonlara göre etkilenir — cross‑region replication compliance'a dikkat edin.

Ölçeklenebilirlik ve operasyon

• Chaos engineering ile partition senaryolarını test edin ve kullanıcı deneyimine etkilerini ölçün.
• Monitoring: replication lag, write/read latencies, conflict rate gibi metrikleri takip edin.

8. SIK YAPILAN HATALAR

• Tutarlılık ihtiyaçlarını belirlemeden tek bir model uygulamak — over/under engineering riskleri.
• Conflict resolution stratejisini test etmeden eventual model kullanmak — veri bozulmaları ortaya çıkar.
• Session guarantees veya monotonic read gibi kullanıcı‑odaklı garantileri atlamak — kötü kullanıcı deneyimi oluşur.

9. GELECEK TRENDLER

1. Adaptive consistency: Sistem telemetriye göre tutarlılık seviyesini dinamik olarak ayarlayacak (AI destekli).
2. CRDT ve convergent data structures: Offline‑first ve edge senaryolarında daha geniş adoption.
3. Hybrid models: Per‑request veya per‑domain tutarlılık ayarlarıyla karma modeller yaygınlaşacak.
4. Serverless distributed patterns: Function‑level consistency kontrolleri ile daha ince granular destekler ortaya çıkacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Strong consistency her zaman gerekli mi?

   Hayır. Güçlü tutarlılık bazı kritik path'lerde gereklidir; fakat genel uygulama yükünün tamamında strong consistency performans ve availability maliyetleri doğurur. Domain'e göre seçin.

2. 2. Eventual consistency nasıl güvenli hale getirilir?

   CRDT'ler, vector clocks, idempotency ve application driven reconciliation stratejileri ile eventual consistency kontrollü ve güvenli hale getirilebilir.

3. 3. Causal consistency uygulamak zor mu?

   Causal consistency metadata (dependency tracking) gerektirir ancak sosyal ve collaborative senaryolarda kullanıcı semantiğini koruması nedeniyle uygulanmaya değerdir.

4. 4. Tunable consistency ne zaman kullanılmalı?

   Performans veya latency ihtiyaçlarına göre read/write quorum ayarlarını değiştirmek istediğinizde; özellikle geo‑distributed replikasyonlarda faydalıdır.

5. 5. CRDT nedir ve nerede kullanılmalı?

   CRDT, conflict‑free replicated data type. Offline/partition koşullarında otomatik birleşme sağlayan veri tipleri için uygundur (örn. collaborative editing, counters, sets).

6. 6. Monotonic reads neden önemlidir?

   Bir kullanıcının önceki okumasından daha eski veriyi tekrar görmesini engeller; kullanıcı deneyimini bozan geri adımları önler.

7. 7. Hangi veri tabanları hangi modelleri destekliyor?

   Spanner/TrueTime güçlü global consistency sunar; Cassandra/DynamoDB genelde tunable/eventual modeller sunar; CosmosDB farklı consistency seviyeleri (strong, bounded staleness, session, consistent prefix, eventual) sağlar.

8. 8. Tutarlılık testlerini nasıl yaparım?

   Mini cluster ile partition senaryoları oluşturun, chaos engineering araçlarıyla ağ bölünmesi simüle edin ve uygulama davranışını SLA'lara göre doğrulayın.

Anahtar Kavramlar

Linearizability

Gerçek zamanlı ordering ile güçlü tutarlılık.

Causal consistency

Neden‑sonuç ilişkilerini koruyan tutarlılık seviyesi.

Eventual consistency

Uzun dönemde tutarlılık garantisi; anlık tutarsızlıklar kabul edilir.

CRDT

Çakışmasız birleşme sağlayan replikasyon veri tipleri.

Tunable consistency

R/W quorum ayarlarıyla dinamik tutarlılık dengesi.

Öğrenme Yol Haritası

1. 0–1 ay: Temel dağıtık sistem kavramları: replication, sharding, CAP teoremi ve basit replikasyon modelleri.
2. 1–3 ay: Consistency modellerini kavrayın: linearizability, sequential, causal, eventual; küçük uygulamalarla deneyin.
3. 3–6 ay: CRDT'ler, vector clocks ve tunable quorum uygulamaları üzerinde çalışın; mini cluster ile partition testleri yapın.
4. 6–12 ay: Production senaryoları: chaos engineering, monitoring, SLA tanımları ve hybrid consistency stratejileri geliştirin.