Mimari ve Dağıtık Sistemler
Biraz Dağıtık Düşünelim: Dağıtık Sistemlerin Teorik Temelleri
Biraz Dağıtık Düşünelim: Dağıtık Sistemlerin Teorik Temelleri
CAP, PACELC, FLP ve mantıksal saatler dağıtık sistemde neyin imkânsız olduğunu söyler; iyi mimari bu sınırları bilerek seçim yapmaktır ve 2025-2026'nın büyük kesintileri bunu yeniden gösterdi.
Ağ bölünmesi ve gecikme kaçınılmaz olduğundan dağıtık sistem tutarlılığı bedavaya veremez; iyi mimari, her veri için hangi bedeli ödeyeceğini bilinçli seçer.
CAP, PACELC ve FLP kanıtlanmış sonuçlar; tartışma yalnızca CP/AP etiketlerinin gerçek sistemlere ne kadar oturduğunda.
Zihinsel model
Dağıtık sistem, telefonu bazen çekmeyen iki muhasebecidir: ya hat gelene kadar işlemi durdurursunuz ya da defterleri sonradan uzlaştırırsınız.
Neden
- Bölünme bir tercih değil olaydır; o anda sistem ya isteği reddeder ya eski veriyle yanıt verir.
- Bölünme yokken de güçlü tutarlı yazma replika onayını bekler; her yazma gecikme bedeli öder.
- Asenkron ağda yavaş düğüm ile çökmüş düğüm ayırt edilemez; zaman aşımı bu yüzden bir risk tercihidir.
Kanıt
Dokümantasyonu hem linearizable hem her zaman erişilebilir olduğunu söyleyen NATS JetStream, çoğunluk yokken erişilemez hale geldi.
Jepsen, NATS 2.12.1 (2025)AWS'nin yaklaşık 14,5 saat süren bölge kesintisinin kök nedeni, DynamoDB DNS yönetiminde eski planı yenisinin üstüne yazan bir yarış durumuydu.
AWS, Summary of the Amazon DynamoDB Service Disruption (2025)MariaDB Galera Cluster'da hiçbir arıza yokken bile Lost Update ve stale read görüldü.
Jepsen, MariaDB Galera Cluster 12.1.2 (2026)Karşı görüş
Bölünme pratikte nadirdir ve iyi yönetilen ağda CP bir sistem çok yüksek erişilebilirlik sunar; CP/AP etiketi gerçek sistemleri tarif etmekte yetersiz kalır. Spanner gibi tasarımlar saati belirsizlik aralığıyla yöneterek sınırı pahalı altyapıyla esnetir.
Kavramlar
Pratikte
- Veritabanı seçerken normal gündeki yazma gecikmesini hangi tutarlılık seviyesi için ödediğinizi sorun.
- Duvar saatiyle last-write-wins yerine mantıksal saat ve idempotency key kullanın.
- Tutarlılık iddiasına güvenmeden önce fsync varsayılanını ve bağımsız Jepsen analizini okuyun.
Bir uygulama tek sunucudan çıkıp ikinci bir veritabanı replikasına, bir kuyruğa ya da bir önbelleğe dokunduğu anda dağıtık sistem olur; ağ, saat ve arıza problemleri kendiliğinden gelir. Konunun teorik temelleri şunlar: CAP ve onu genişleten PACELC, uzlaşının neden zor olduğunu kanıtlayan FLP sonucu, Paxos ve Raft gibi consensus algoritmaları ve fiziksel saatlere neden güvenilmediği. Bu sorular artık küçük ekiplerin de önünde: serverless, çok bölgeli SQL veritabanları ve aynı durumu paylaşan birden fazla agent. Ekim 2026 itibarıyla teori yeniden gündemde, çünkü Ekim 2025'teki AWS us-east-1 kesintisinin kök nedeni DynamoDB'nin DNS yönetimindeki bir yarış durumuydu, Jepsen'in Aralık 2025 ve Mart 2026 analizleri de NATS ve MariaDB Galera'da onaylanmış yazmaların kaybolabildiğini gösterdi. Teoriyi bilmek, bir veritabanının pazarlama sayfasındaki iddiayı okuyabilmek demek.
Çıkarımlar
- CAP'te asıl seçim, ağ bölündüğünde isteği reddetmek mi eski veriyle yanıt vermek mi sorusudur.
- PACELC'yi hatırlayın: bölünme yokken bile her güçlü tutarlı yazma gecikme bedeli öder.
- FLP yüzünden zaman aşımı değerinin doğru cevabı yoktur; bilinçli bir risk tercihidir.
- 3 düğüm 1, 5 düğüm 2 arızayı tolere eder; 4 düğüm toleransı artırmaz.
- Duvar saatiyle last-write-wins sessiz veri kaybı üretebilir; mantıksal saat ve idempotency key kullanın.
- Onaylanmış yazma kalıcı yazma demek değildir; seçtiğiniz sistemin fsync varsayılanını ve Jepsen analizini okuyun.
Alt başlıklar
CAP teoremi: doğru okunması gereken bir sınır
CAP, Eric Brewer'ın 2000'deki bir konuşmasında ortaya attığı ve Gilbert ile Lynch'in 2002'de biçimsel olarak kanıtladığı sonuç. Bir ağ bölünmesi (partition) sırasında sistem ya tutarlılıktan (Consistency, burada linearizability anlamında) ya da erişilebilirlikten (Availability, her sağlıklı düğümün her isteğe yanıt vermesi) vazgeçmek zorunda.
En yaygın yanlış okuma, üç özellikten ikisini seç sloganı. Partition bir tercih değil, ağ olduğu sürece olacak bir olay. Asıl seçim, bölünme anında ne yapacağınız: isteği reddetmek mi (CP), eski veriyle yanıt vermek mi (AP).
Somut senaryo: İstanbul ve Frankfurt'ta iki replika var, aradaki bağlantı koptu. Bir kullanıcı Frankfurt'ta stok güncelliyor. CP bir sistem İstanbul'daki okumayı reddeder; AP bir sistem eski stoğu gösterir. Biletleme için CP, beğeni sayacı için AP mantıklı. Aynı ürünün farklı özellikleri farklı seçim isteyebilir. Bir dokümantasyon hem linearizable hem her koşulda erişilebilir olduğunu söylüyorsa dikkat: Jepsen Aralık 2025'te NATS JetStream için tam bu çelişkiyi raporladı; sistem pratikte tipik bir Raft uygulaması gibi çoğunluk yoksa erişilemez hale geliyordu.
Ekim 2026 itibarıyla durum
Teori değişmedi, ama son 12 ay onu doğrulayan olaylarla doldu.
Kesintiler: 19-20 Ekim 2025'te AWS us-east-1'de yaklaşık 14,5 saat süren olayın kök nedeni, DynamoDB DNS yönetimindeki iki bileşenin eski bir planı yenisinin üstüne yazdığı gizli bir yarış durumuydu. 18 Kasım 2025'teki Cloudflare kesintisinde ise boyutu ikiye katlanan bir yapılandırma dosyası tüm ağa yayıldı ve çekirdek proxy'yi çökertti. İkisi de koordinasyon ve yayılım problemleri; ikisinde de tek bir bileşenin hatalı durumu, onu doğrulamadan kabul eden diğer bileşenler üzerinden bütün sisteme taşındı.
Doğrulama: Jepsen, Aralık 2025'te NATS JetStream 2.12.1'de varsayılan lazy fsync yüzünden güç kesintisinde onaylanmış yazmaların kaybolabildiğini ve dokümantasyonun hem linearizable hem her zaman erişilebilir iddiasının CAP ile çeliştiğini gösterdi. Mart 2026'da MariaDB Galera Cluster 12.1.2'de arıza olmadan bile Lost Update ve stale read buldu.
Ders: bir sistemin dokümantasyonundaki tutarlılık iddiası, bağımsız bir test görmeden tasarım varsayımı yapılmamalı.
Kaynaklar: Designing Data-Intensive Applications'ın Martin Kleppmann ve Chris Riccomini imzalı ikinci baskısı Şubat 2026'da çıktı. MIT'nin 6.5840 dersi 2026 baharında da güncel okuma listesiyle verildi.
PACELC: bölünme yokken de bedel var
Daniel Abadi'nin 2012'de IEEE Computer'da yayımlanan makalesi, CAP'in eksik bıraktığı bir noktayı yakaladı: ağ bölünmesi nadirdir, ama replikasyonun bedeli her an ödenir. PACELC şöyle okunur: Partition varsa (P) Availability ile Consistency arasında seç (A/C); Else, yani her şey normalken (E), Latency ile Consistency arasında seç (L/C).
Normal günde güçlü tutarlılık, yazmanın diğer replikalardan onay beklemesi demek. Replikalar farklı kıtalardaysa bu, her yazmaya onlarca ila yüzlerce milisaniye ekleyebilir. Bu yüzden birçok sistem varsayılan olarak düşük gecikmeyi seçip tutarlılığı gevşetir.
Abadi'nin sınıflandırmasında Dynamo ve Cassandra gibi sistemler varsayılan ayarlarıyla PA/EL, tam ACID dağıtık sistemler PC/EC tarafında. Bulut sağlayıcıları bu ödünleşimi ürünleştiriyor: Mayıs 2025'te genel kullanıma açılan Aurora DSQL, çok bölgeli güçlü tutarlılık ve senkronize zaman vaat ediyor; ama bunu üçüncü bir bölgede tanık log tutarak ve yazma yolunda bölgeler arası koordinasyonla sağlıyor, yani EC tarafında duruyor.
Pratik değer: bir veritabanı seçerken soru 'CAP'te nerede' değil, 'normal gündeki yazma gecikmesini hangi tutarlılık seviyesi için ödüyorum' olmalı.
FLP imkânsızlığı: uzlaşının sınırı
Fischer, Lynch ve Paterson'ın 1985 tarihli sonucu şunu söylüyor: tamamen asenkron bir sistemde, yani mesajların ne kadar gecikeceği hakkında hiçbir üst sınırın olmadığı bir ortamda, tek bir sürecin bile çökebildiği durumda, her zaman sonlanmayı garanti eden deterministik bir consensus algoritması yoktur.
Bu ilk bakışta teorik bir kuriozite gibi duruyor, ama pratikte çok şey açıklıyor. Bir düğüm yanıt vermediğinde ağ mı yavaş, düğüm mü çöktü, asenkron modelde ayırt edemezsiniz. Paxos ve Raft gibi algoritmalar bu sınırı inkâr etmez; güvenliği (yanlış karar vermemek) her koşulda korur, canlılığı (bir gün karar vermek) ise zaman aşımları ve kısmi senkronluk varsayımıyla sağlar.
Günlük karşılığı: zaman aşımı değeri bir mühendislik tercihidir, doğru bir değeri yoktur. Çok kısa tutarsanız gereksiz lider seçimleri ve split brain riski artar, çok uzun tutarsanız gerçek arızada sistem uzun süre bekler.
Consensus: quorum, Paxos ve Raft
Consensus (uzlaşı), birden fazla düğümün tek bir değer ya da işlem sırası üzerinde, bazıları arızalansa bile anlaşması problemi. Temel araç quorum (çoğunluk): 2f+1 düğümlü bir küme, çökme türü f arızayı tolere eder. Yani 3 düğüm 1 arızayı, 5 düğüm 2 arızayı kaldırır. 4 düğüm kurmak, 3 düğüme göre arıza toleransını artırmaz, sadece çoğunluk eşiğini yükseltir.
Paxos, Lamport'un bu problemi çözen klasik algoritması; doğruluğu güçlü ama anlaşılması ve uygulanması zor olarak bilinir. Raft, 2014'te Ongaro ve Ousterhout tarafından anlaşılabilirlik hedefiyle tasarlandı: lider seçimi, log replikasyonu ve güvenlik kurallarını ayrı parçalara böler. etcd, Consul ve CockroachDB gibi sistemler Raft kullanır.
Kötü niyetli ya da yalan söyleyen düğümler hesaba katılırsa problem Byzantine fault tolerance olur ve f arıza için 3f+1 düğüm gerekir. Blokzincir tartışmalarındaki uzlaşı mekanizmaları bu ailenin parçası.
Zaman ve saatler: neden duvar saatine güvenmeyiz
Fiziksel saatler kayar. NTP ile senkronize edilmiş sunucular arasında bile milisaniyeler mertebesinde, kötü durumlarda çok daha büyük farklar olabilir; saat geri de atlayabilir. Bu yüzden 'son yazan kazanır' (last write wins) stratejisini zaman damgasıyla uygulamak, saati önde olan sunucunun yazmasının diğerlerini sessizce ezmesine yol açabilir.
Lamport 1978'de mantıksal saatleri önerdi: her olay bir sayaç artırır, mesajla gelen sayaç yerel olandan büyükse güncellenir. Bu, happens-before (önce olma) ilişkisini korur ama iki olayın eşzamanlı olup olmadığını söyleyemez. Vector clock her düğüm için ayrı sayaç tutarak eşzamanlılığı da tespit eder; bedeli düğüm sayısıyla büyüyen meta veri.
Google Spanner farklı bir yol seçti: TrueTime, saati tek bir değer yerine bir belirsizlik aralığı olarak verir ve sistem işlem onayında bu aralık kadar bekler. Hybrid logical clock ise fiziksel saat ile mantıksal sayacı birleştirip ikisinin avantajını almaya çalışır.
Tutarlılık modelleri ve gündelik mühendislik
Tutarlılık ikili değil, bir spektrum. En güçlü uçta linearizability var: sistem tek bir kopya varmış gibi davranır. Ortada causal consistency, yani nedensel olarak bağlı işlemlerin herkes tarafından aynı sırada görülmesi. Zayıf uçta eventual consistency: yeni yazma gelmezse replikalar eninde sonunda aynı değere yakınsar, ama ne zaman olacağı garanti edilmez.
Kullanıcı deneyiminde en sık görülen hata read-your-writes ihlali: kullanıcı profilini günceller, sayfa yenilenir, okuma eski replikaya gider ve eski bilgi görünür. Çözüm her şeyi güçlü tutarlı yapmak değil; yazmadan sonraki birkaç saniye o kullanıcının okumalarını birincil düğüme yönlendirmek gibi hedefli bir garanti.
Bir diğer pratik araç idempotency key. Ağ hatasında istemci isteği tekrar gönderir; sunucu aynı anahtarı ikinci kez görünce işlemi tekrarlamaz. Ödeme ve sipariş gibi akışlarda bu, exactly-once teslimat vaadinden çok daha gerçekçi bir güvencedir.
Bir de onay ile kalıcılık arasındaki farkı unutmayın. Jepsen'in 2025-2026 analizleri, varsayılan ayarlarda diske yazmadan önce onay veren sistemlerin güç kesintisinde onaylanmış yazmaları kaybedebildiğini gösterdi. 'Yazıldı' yanıtının hangi fsync politikasıyla verildiğini bilmeden tutarlılık modeli konuşmak eksik kalır.
Son gelişmeler
Ekim 2026 itibarıyla
Önce kendi cevabını düşün, sonra aç.
Tek bir Postgres kullanan bir startup'ın bu teoriye ihtiyacı var mı?
Tek Postgres'in içinde bile okuma replikası, Redis önbelleği, bir kuyruk ve üçüncü taraf API varsa zaten dağıtık bir sisteminiz var. Read-your-writes ihlali, çift işlenen webhook ve önbellek tutarsızlığı bu teorinin gündelik yüzü. Teoriyi bilmek, bu hataları isimlendirip doğru araçla çözmenizi sağlar.
Bazı veritabanları hem güçlü tutarlı hem yüksek erişilebilir olduğunu söylüyor; CAP yanlış mı?
CAP yanlış değil, iddiaların çoğu tanımları farklı kullanıyor. Pratikte 'yüksek erişilebilirlik' yüzde 99,99 gibi bir operasyonel hedeftir, CAP'teki her sağlıklı düğümün yanıt vermesi tanımı değildir. Bölünmenin nadir olduğu ve iyi yönetildiği bir ağda CP bir sistem çok yüksek erişilebilirlik sunabilir, ama bölünme anında yine bir tarafı reddeder. Jepsen'in Aralık 2025 NATS analizi, dokümantasyonda iki özelliği birden vaat eden bir sistemin pratikte çoğunluk yoksa erişilemez olduğunu gösterdi.
FLP consensus'u imkânsız diyorsa Raft nasıl çalışıyor?
FLP, tamamen asenkron modelde her durumda sonlanmayı garanti etmenin imkânsız olduğunu söylüyor. Raft güvenliği her koşulda korur, canlılık için ise ağın çoğu zaman makul sürede mesaj ilettiğini varsayar ve zaman aşımları kullanır. Yani Raft sınırı aşmıyor, varsayımı değiştiriyor.
Exactly-once mesaj teslimatı mümkün mü?
Ağ üzerinden, genel durumda, uçtan uca tam bir kez teslimatı garanti etmek mümkün değil; mesaj ya kaybolabilir ya tekrarlanabilir. Sistemlerin exactly-once dediği şey genellikle en az bir kez teslimat artı idempotent işleme ya da işlemsel deduplikasyon. Tasarımı bu gerçeğe göre yapmak daha güvenli.
Notun kaynakları
- Daniel Abadi - Consistency Tradeoffs in Modern Distributed Database System Design (PACELC)
- The Raft Consensus Algorithm
- Leslie Lamport - Time, Clocks, and the Ordering of Events in a Distributed System (CACM 1978)
- Jepsen - NATS 2.12.1 (Aralık 2025)
- Jepsen - MariaDB Galera Cluster 12.1.2 (Mart 2026)
- Cloudflare outage on November 18, 2025
- AWS - Amazon Aurora DSQL is now generally available (Mayıs 2025)
Sunum stili
11 slayt. Tıklarsan sunum o slayttan başlar.
Slayt notları
Teoriyi bilmek, bir veritabanının pazarlama sayfasındaki iddiayı okuyabilmek demek. Beş fikirle ilerliyorum.
Şu soruyla açıyorum: okuma replikası, Redis, bir kuyruk ya da ödeme webhook'u kullanan kaç sistem tanıyorsunuz? Cevap hemen hepsi; teorinin herkesi ilgilendirmesi bu yüzden.
Teorinin sonuçları bugün kullandığımız veritabanlarının ve koordinasyon servislerinin altında çalışıyor; 2025-2026 olayları da bunu yeniden hatırlattı.
İstanbul ve Frankfurt replikası arasındaki bağlantı koptu. CP sistem okumayı reddeder, AP sistem eski stoğu gösterir. Biletlemede CP, beğeni sayacında AP mantıklı.
Kıtalar arası güçlü tutarlı her yazma onlarca ila yüzlerce milisaniye ekleyebilir. Doğru soru 'CAP'te neredesin' değil, 'normal günde hangi tutarlılık için gecikme ödüyorum'.
FLP bunu söylüyor. Kısa timeout gereksiz lider seçimi ve split brain riski getirir; uzun timeout gerçek arızada sistemi bekletir.
2f+1 düğüm f çökme arızasını kaldırır. Dördüncü düğüm toleransı artırmaz, sadece çoğunluk eşiğini yükseltir. Raft'ı etcd, Consul ve CockroachDB kullanıyor; yalan söyleyen düğümler için 3f+1 gerekir.
Duvar saatiyle last-write-wins, saati önde olan sunucunun diğerlerini sessizce ezmesi demek. Lamport happens-before'u korur, vector clock eşzamanlılığı da yakalar, TrueTime saati bir belirsizlik aralığı olarak verir.
En sık kullanıcı hatası read-your-writes ihlali: profil güncellenir, sayfa yenilenir, eski bilgi görünür. Çözüm her şeyi güçlü tutarlı yapmak değil, yazmadan sonra o kullanıcının okumalarını birincil düğüme yönlendirmek.
Exactly-once teslimat vaadi yerine bu desen ödeme ve sipariş akışlarında çok daha gerçekçi bir garanti verir. Bir de sunucunun 'yazıldı' yanıtını hangi fsync politikasıyla verdiğini öğrenin.
Bir sonraki veritabanı seçiminde pazarlama sayfasını bu sorularla okuyun: partition, gecikme, timeout, quorum, saat, fsync. Ardından Jepsen analizi varsa onu okuyun.