CAP Teoremi, dağıtık sistemlerde tutarlılık, erişilebilirlik ve ağ bölünmesine dayanıklılık özelliklerinin aynı anda mutlak biçimde garanti edilemeyeceğini açıklayan temel bilgisayar bilimi ilkesidir. İngilizcede Consistency, Availability, Partition Tolerance kelimelerinin baş harflerinden oluşur. Türkçeye “Tutarlılık, Erişilebilirlik ve Bölünme Toleransı Teoremi” olarak çevrilebilir.
CAP Teoremi özellikle dağıtık veritabanları, NoSQL sistemleri, mikroservis mimarileri, bulut altyapıları, data lake, lakehouse, büyük veri sistemleri ve yüksek erişilebilirlik gerektiren uygulamalar için kritik öneme sahiptir. Çünkü modern yazılımlar çoğu zaman tek bir sunucuda çalışmaz. Veriler birden fazla makineye, veri merkezine, bölgeye veya bulut ortamına dağılır. Bu dağılım ölçeklenebilirlik ve dayanıklılık sağlar; fakat aynı zamanda veri tutarlılığı, sistem erişilebilirliği ve ağ hataları arasında zor tasarım kararları doğurur.
CAP Teoremi’nin en basit anlatımı şudur: Bir dağıtık sistemde ağ bölünmesi yaşandığında sistem ya tutarlılığı korumak için bazı isteklere cevap vermemeyi seçer ya da erişilebilir kalmak için bazı kullanıcılara eski veya henüz senkronize olmamış veri gösterebilir. Yani gerçek gerilim çoğu zaman “üçünden ikisini seç” şeklinde değil, “ağ bölünmesi sırasında tutarlılık mı, erişilebilirlik mi?” şeklinde ortaya çıkar.
Bu ayrım önemlidir. CAP Teoremi çoğu zaman yanlış biçimde “bir sistem sadece iki özelliğe sahip olabilir” diye anlatılır. Oysa ağ sorunu yokken birçok dağıtık sistem hem tutarlı hem erişilebilir görünebilir. Problem, ağ bölünmesi veya iletişim kopukluğu yaşandığında belirginleşir. Dağıtık sistemler gerçek dünyada ağ hatalarından tamamen kaçamayacağı için “partition tolerance” çoğu pratik sistemde vazgeçilmez kabul edilir. Bu durumda esas tercih “consistency” ile “availability” arasında yapılır.
CAP Teoremi, yazılım mimarlarına şunu hatırlatır: Dağıtık sistem tasarımı yalnızca daha fazla sunucu eklemek değildir. Her veri türü aynı tutarlılık gereksinimine sahip değildir. Banka hesabı bakiyesi, sosyal medya beğeni sayısı, alışveriş sepeti, stok miktarı, mesajlaşma durumu, ödeme işlemi ve analitik sayaç aynı şekilde tasarlanamaz. Bazı durumlarda eski veri göstermek kabul edilebilir; bazı durumlarda ise yanlış veri göstermek sistemin güvenilirliğini yok eder.
CAP Teoremi Nedir?
CAP Teoremi, dağıtık bir veri sisteminin aynı anda üç temel özelliği mutlak biçimde sağlayamayacağını ifade eder: Tutarlılık, erişilebilirlik ve bölünme toleransı. Bu üç özellik İngilizce adlarıyla consistency, availability ve partition tolerance olarak bilinir.
Consistency, sistemdeki tüm kullanıcıların en güncel ve aynı veriyi görmesini ifade eder. Bir yazma işlemi gerçekleştiyse, sonraki okuma işlemleri bu en son değeri görmelidir. CAP bağlamındaki consistency, çoğu zaman linearizability veya atomic consistency anlamına yakın kullanılır.
Availability, sistemin kendisine gelen her geçerli isteğe hata vermeden cevap üretmesini ifade eder. Burada cevap en güncel veri olmak zorunda değildir. Önemli olan, sistemin cevap verebilmesidir.
Partition tolerance, sistemin ağdaki iletişim kopukluklarına rağmen çalışmaya devam edebilmesidir. Dağıtık sistemlerde makineler birbirleriyle ağ üzerinden konuşur. Bu ağda gecikme, kopma, paket kaybı veya veri merkezi ayrışması yaşanabilir. Partition tolerance, bu tür durumlarda sistemin tamamen çökmeden davranış belirleyebilmesini ifade eder.
CAP Teoremi’nin özü şudur: Eğer dağıtık sistemin parçaları arasında iletişim koparsa, sistem aynı anda hem herkesin en güncel veriyi görmesini hem de herkesin her isteğine cevap almasını garanti edemez. Bir tercih yapılır. Ya bazı isteklere cevap verilmez ve tutarlılık korunur ya da sistem cevap vermeye devam eder ama bazı cevaplar eski veya tutarsız olabilir.
CAP Teoremi Ne Anlama Gelir?
CAP Teoremi, dağıtık sistem tasarımında kaçınılmaz bir gerilimi görünür kılar. Tek makinede çalışan basit bir sistemde veri tek yerde durur. Okuma ve yazma işlemleri aynı kaynağa gider. Ancak sistem dağıtıldığında veri birden fazla kopyaya sahip olabilir. Bir kullanıcı İstanbul’daki sunucuya, başka bir kullanıcı Frankfurt’taki sunucuya, başka biri Singapur’daki sunucuya bağlanabilir. Bu yapı hızlı erişim ve dayanıklılık sağlar; fakat veri kopyalarının aynı anda güncel kalmasını zorlaştırır.
Örneğin bir kullanıcı hesabındaki bakiyeyi güncellediğinde bu bilgi tüm veri merkezlerine anında ulaşmayabilir. Ağ gecikmesi veya kopması varsa bazı sunucular eski bakiyeyi gösterebilir. Sistem bu durumda ne yapmalıdır? Eski veriyi göstermek riskli midir? Kullanıcıya hata vermek daha mı doğrudur? İşlem bekletilmeli midir? Bu sorular CAP Teoremi’nin pratik karşılığıdır.
CAP Teoremi, sistem tasarımcısına kesin bir reçete vermez. “Her zaman tutarlılığı seç” veya “her zaman erişilebilirliği seç” demez. Bunun yerine tercihlerin farkında olmayı sağlar. Hangi veri için hangi özellik daha önemli? Ağ bölünmesi durumunda sistem nasıl davranmalı? Kullanıcıya hata göstermek mi daha iyi, eski veri göstermek mi? Bu karar iş bağlamına göre değişir.
CAP Teoremi Neden Ortaya Çıktı?
CAP fikri, internet ölçeğinde çalışan sistemlerin yaygınlaşmasıyla önem kazandı. Erken dönem kurumsal yazılımlarda veriler çoğu zaman merkezi ilişkisel veritabanlarında tutuluyordu. Bu sistemler güçlü tutarlılık, işlemsel güvenilirlik ve merkezi kontrol açısından başarılıydı. Ancak internet uygulamaları büyüdükçe tek merkezli sistemler ölçeklenebilirlik ve erişilebilirlik sorunları yaşamaya başladı.
Büyük web uygulamaları milyonlarca kullanıcıya hizmet vermek zorundaydı. Kullanıcılar farklı ülkelerden bağlanıyordu. Sistemlerin kesintisiz çalışması, yüksek trafik altında cevap vermesi ve veri merkezi arızalarına dayanması gerekiyordu. Bu durum verinin birden fazla sunucuya ve bölgeye dağıtılmasını zorunlu hâle getirdi.
Dağıtık sistemler ölçeklenebilirliği artırdı; fakat yeni sorunlar doğurdu. Veri kopyaları nasıl senkronize edilecekti? Bir sunucu diğerinden koparsa ne olacaktı? Kullanıcılar farklı kopyalardan farklı sonuçlar görürse sistem güvenilir sayılacak mıydı? CAP Teoremi bu soruların teorik çerçevesini sundu.
Eric Brewer, 2000 yılında CAP ilkesini bir varsayım olarak ortaya koydu. Seth Gilbert ve Nancy Lynch ise 2002 yılında bu varsayımı formel olarak ele aldı ve dağıtık sistemlerde tutarlılık, erişilebilirlik ve bölünme toleransı arasındaki imkânsızlık ilişkisini matematiksel olarak gösterdi. Bu nedenle CAP Teoremi bazen Brewer Teoremi olarak da adlandırılır.
Consistency Nedir?
Consistency, CAP bağlamında tüm istemcilerin sistemden aynı ve en güncel veriyi okuması anlamına gelir. Bir yazma işlemi başarıyla tamamlandıysa, ondan sonra yapılan okuma işlemleri bu yazmanın sonucunu görmelidir. Eğer sistem bunu garanti edemiyorsa, eski veri döndürmek yerine hata verebilir veya işlemi bekletebilir.
CAP bağlamındaki consistency ile ACID içindeki consistency aynı şey değildir. ACID’de consistency, veritabanının tanımlı kurallar ve bütünlük kısıtları açısından geçerli durumda kalması anlamına gelir. CAP’teki consistency ise daha çok dağıtık kopyalar arasında güncel değerin görünmesiyle ilgilidir.
Örneğin bir e-ticaret sisteminde ürün stoğu 1 adet kaldıysa ve iki kullanıcı aynı ürünü aynı anda satın almaya çalışıyorsa tutarlılık kritik olabilir. Sistem iki kullanıcıya da başarılı satış yaparsa stok negatife düşer. Bu durumda güçlü tutarlılık gerekir. Sistem gerekirse ikinci kullanıcıya hata vermeli veya işlemi reddetmelidir.
Başka bir örnekte sosyal medya beğeni sayısı birkaç saniye eski görünebilir. Bir kullanıcının 100 yerine 98 beğeni görmesi çoğu durumda kritik değildir. Bu durumda sistem daha gevşek tutarlılıkla çalışabilir. Consistency gereksinimi verinin iş değerine göre değişir.
Availability Nedir?
Availability, sistemin kendisine gelen her geçerli isteğe cevap verebilmesidir. CAP bağlamında availability, sistemin her zaman en güncel veya en doğru cevabı verdiği anlamına gelmez. Anlamı şudur: Çalışan bir düğüme gelen istek cevapsız kalmaz.
Availability, kullanıcı deneyimi açısından çok önemlidir. Bir haber sitesinin, sosyal medya akışının, ürün arama ekranının veya öneri sisteminin sürekli cevap verebilmesi beklenir. Bazı durumlarda biraz eski veri göstermek, hiç cevap vermemekten daha kabul edilebilir olabilir.
Ancak availability mutlak biçimde seçildiğinde consistency zayıflayabilir. Ağ bölünmesi sırasında her düğüm kendi bildiği veriyle cevap vermeye devam ederse, farklı kullanıcılar farklı sonuçlar görebilir. Bu durum bazı sistemlerde kabul edilebilir, bazılarında edilemez.
Örneğin mesajlaşma uygulamasında “son görülme” bilgisinin birkaç saniye eski olması genellikle sorun değildir. Ancak banka transferinde hesap bakiyesinin eski görünmesi ciddi risk yaratabilir. Bu nedenle availability değerli olsa da her veri türü için aynı önceliğe sahip değildir.
Partition Tolerance Nedir?
Partition tolerance, sistemin ağ bölünmelerine rağmen çalışmaya devam edebilmesidir. Dağıtık sistemlerde ağ güvenilmezdir. Sunucular birbirinden kopabilir, mesajlar gecikebilir, paketler kaybolabilir veya bir veri merkezi diğerleriyle iletişim kuramaz hâle gelebilir. Bu tür durumlara network partition denir.
Partition, sistemin fiziksel olarak tamamen çökmesi değildir. Bazı parçalar çalışmaya devam edebilir; fakat birbirleriyle konuşamaz. Örneğin iki veri merkezi ayakta olabilir ama aralarındaki bağlantı kopmuş olabilir. Her iki taraf da kullanıcı istekleri almaya devam eder. Sorun şudur: Bu iki taraf birbirinden habersiz işlem yaparsa veri nasıl tutarlı kalacaktır?
Dağıtık sistemlerde partition tolerance çoğu zaman kaçınılmazdır. Çünkü gerçek dünyada ağ hatalarını tamamen ortadan kaldırmak mümkün değildir. Bu nedenle pratikte “P’den vazgeçelim” demek çoğu zaman gerçekçi değildir. Ağ bölünmeleri yaşanabileceğine göre sistemin bu durumda nasıl davranacağı tasarlanmalıdır.
CAP Teoremi Nasıl Çalışır?
CAP Teoremi’ni anlamanın en iyi yolu basit bir dağıtık sistem örneği düşünmektir. Bir veritabanının iki kopyası olsun; biri A veri merkezinde, diğeri B veri merkezinde. Normal durumda iki veri merkezi birbiriyle konuşur. A’ya yazılan veri B’ye de aktarılır. Kullanıcılar hangi veri merkezine bağlanırsa bağlansın güncel veriyi görür.
Şimdi A ve B veri merkezleri arasındaki ağ bağlantısının koptuğunu düşünelim. A veri merkezi kendi kullanıcılarından istek almaya devam ediyor. B veri merkezi de kendi kullanıcılarından istek almaya devam ediyor. Ancak A ve B birbirleriyle konuşamıyor.
Bu durumda sistemin iki temel seçeneği vardır:
- Tutarlılığı Korumak: Sistem, güncel veri garantisi veremediği için bazı yazma veya okuma isteklerini reddeder. Böylece yanlış veya eski veri gösterme riskini azaltır. Ancak availability düşer.
- Erişilebilirliği Korumak: Sistem, her iki tarafta da isteklere cevap vermeye devam eder. Kullanıcılar hizmet alır. Ancak A ve B farklı veri durumlarına sahip olabilir. Böylece consistency zayıflar.
Bu, CAP Teoremi’nin özüdür. Ağ bölünmesi sırasında sistem hem “her zaman cevap vereceğim” hem de “her zaman en güncel ve tek doğru veriyi göstereceğim” garantisini aynı anda veremez. Bir tercih yapmak zorundadır.
CAP Teoremi Neden “Üçünden İkisini Seç” Diye Anlatılır?
CAP Teoremi popüler olarak “consistency, availability ve partition tolerance arasından sadece ikisini seçebilirsin” şeklinde anlatılır. Bu ifade öğretici olarak yararlı olabilir; fakat eksiktir. Çünkü pratik dağıtık sistemlerde partition tolerance çoğu zaman zorunludur. Ağ bölünmeleri yaşanabilir. Bu nedenle gerçek tercih çoğu zaman consistency ve availability arasındadır.
“Üçünden ikisini seç” ifadesi şu açıdan yanıltıcıdır: Ağ bölünmesi yokken bir sistem hem tutarlı hem erişilebilir olabilir. Problem partition yaşandığında ortaya çıkar. Yani CAP sürekli bir üçlü seçim tablosu değil, hata anındaki davranış kısıtıdır.
Daha doğru anlatım şudur:
- Dağıtık sistemlerde ağ bölünmeleri olabilir.
- Ağ bölünmesi yaşandığında sistem ya tutarlılığı ya da erişilebilirliği feda etmek zorunda kalabilir.
- Bu tercih veri türüne, iş ihtiyacına ve sistem tasarımına göre değişir.
Bu nedenle modern sistem tasarımında CAP, kaba bir etiketleme aracı olarak değil, hata senaryolarında karar verme çerçevesi olarak kullanılmalıdır.
CAP Teoremi Hakkında En Yaygın Yanlış Anlama
CAP Teoremi’nin en yaygın yanlış anlaşılması, veritabanlarını kalıcı biçimde “CP”, “AP” veya “CA” diye etiketlemektir. Bu etiketler öğretici olabilir; ancak modern sistemlerin davranışı çoğu zaman daha karmaşıktır.
Bir sistem bazı operasyonlarda güçlü tutarlılık, bazı operasyonlarda eventual consistency kullanabilir. Aynı veritabanı farklı yapılandırmalarda farklı davranabilir. Okuma ve yazma quorum ayarları, replika sayısı, coğrafi dağılım, lider seçimi, transaction seviyesi ve istemci davranışı sonucu değiştirebilir.
Örneğin bir sistem kullanıcı profil bilgisinde availability odaklı çalışırken, ödeme işleminde consistency odaklı davranabilir. Bu durumda tüm sistemi tek kelimeyle AP veya CP diye sınıflandırmak yetersiz kalır. Doğru soru şudur: Hangi veri yolu, hangi hata senaryosunda, hangi garantiyi veriyor?
CAP Teoremi mimari diyagramlara basit etiket yapıştırmak için değil, sistemin hata anındaki davranışını düşünmek için kullanılmalıdır.
CP, AP ve CA Sistemleri Nedir?
CP Sistemleri
CP, consistency ve partition tolerance öncelikli sistemleri ifade eder. Ağ bölünmesi yaşandığında sistem tutarlılığı korumayı seçer. Bunu yaparken bazı isteklere cevap vermeyebilir, hata döndürebilir veya işlemi bekletebilir. Böylece availability azalır.
CP yaklaşımı, yanlış veri göstermenin veya çelişkili yazma işlemlerinin kabul edilemeyeceği alanlarda önemlidir. Ödeme, stok rezervasyonu, kimlik doğrulama, kritik konfigürasyon yönetimi ve finansal kayıtlar buna örnek olabilir.
AP Sistemleri
AP, availability ve partition tolerance öncelikli sistemleri ifade eder. Ağ bölünmesi yaşandığında sistem cevap vermeye devam eder. Ancak bazı cevaplar eski veya tutarsız olabilir. Sistem daha sonra kopyalar arasındaki farkları uzlaştırmaya çalışabilir.
AP yaklaşımı, hizmetin sürekli erişilebilir olmasının tutarlılıktan daha önemli olduğu veya küçük tutarsızlıkların kabul edilebilir olduğu durumlarda kullanışlıdır. Sosyal medya beğeni sayıları, sayaçlar, öneri sistemleri, olay logları ve bazı kullanıcı aktivite kayıtları buna örnek olabilir.
CA Sistemleri
CA, consistency ve availability sağlayan ama partition tolerance sağlamayan sistemleri ifade eder. Ancak gerçek dağıtık sistemlerde ağ bölünmeleri kaçınılmaz olduğu için CA kategorisi pratikte tartışmalıdır. Tek makinede çalışan veya ağ bölünmesini sistem tasarımında dikkate almayan yapılarda CA benzeri davranış görülebilir. Fakat gerçek dağıtık sistemlerde partition tolerance yok sayıldığında sistem ağ hatalarına dayanıklı olmaz.
Bu nedenle modern yorumda “CA dağıtık sistem” ifadesi dikkatle kullanılmalıdır. Eğer sistem gerçekten dağıtılmışsa, partition ihtimali vardır. Partition ihtimali varsa CAP gerilimi devreye girer.
CAP Teoremi ve NoSQL Veritabanları
CAP Teoremi, NoSQL veritabanlarının yükselişiyle birlikte daha fazla tartışılmaya başlamıştır. Çünkü NoSQL sistemleri çoğu zaman yatay ölçeklenebilirlik, yüksek erişilebilirlik ve dağıtık mimari hedefleriyle tasarlanmıştır. Bu sistemlerde verinin birden fazla düğüme dağıtılması doğaldır.
NoSQL dünyasında farklı veritabanları farklı tutarlılık ve erişilebilirlik yaklaşımları sunar. Anahtar-değer depoları, belge tabanlı veritabanları, geniş sütunlu veritabanları ve grafik veritabanları aynı CAP davranışına sahip değildir. Hatta aynı ürün farklı ayarlarla farklı davranabilir.
Örneğin bazı geniş sütunlu sistemler “tunable consistency” sunar. Yani geliştirici okuma ve yazma işlemlerinde kaç replikanın onay vermesi gerektiğini belirleyebilir. Daha fazla replika onayı güçlü tutarlılığa yaklaşırken, daha az replika onayı daha yüksek erişilebilirlik ve düşük gecikme sağlayabilir.
Bu nedenle “NoSQL sistemleri AP’dir” gibi genellemeler doğru değildir. NoSQL geniş bir ailedir. Her sistemin veri modeli, replikasyon stratejisi, quorum ayarları, transaction desteği ve hata davranışı ayrı değerlendirilmelidir.
CAP Teoremi ve ACID Arasındaki Fark
CAP ve ACID sık karıştırılır. İkisi de veri sistemleriyle ilgilidir; fakat farklı sorulara cevap verir.
ACID, veritabanı işlemlerinin güvenilir biçimde yürütülmesi için kullanılan ilkeler bütünüdür: Atomicity, consistency, isolation ve durability. Türkçede atomiklik, tutarlılık, izolasyon ve kalıcılık olarak ifade edilebilir. ACID özellikle transaction yönetimiyle ilgilidir.
CAP ise dağıtık sistemlerde ağ bölünmesi durumunda tutarlılık ve erişilebilirlik arasındaki gerilimle ilgilenir. CAP’teki consistency, ACID’deki consistency ile aynı anlama gelmez. CAP’te consistency, dağıtık kopyalardan okunan verinin en güncel yazmayı yansıtmasıyla ilgilidir. ACID’de consistency, işlemlerden sonra veritabanının tanımlı bütünlük kurallarını bozmamasıyla ilgilidir.
Basit ayrım şöyledir:
- ACID: Bir veritabanı işlemi güvenilir biçimde nasıl yürütülür?
- CAP: Ağ bölünmesi yaşayan dağıtık sistem tutarlılık ve erişilebilirlik arasında nasıl tercih yapar?
Bir sistem ACID transaction desteği sunabilir ve aynı zamanda CAP bağlamında belirli hata senaryolarında availability’den ödün verebilir. Bu nedenle ACID ve CAP birbirinin doğrudan alternatifi değildir.
CAP Teoremi ve BASE Yaklaşımı
BASE, özellikle dağıtık ve yüksek erişilebilirlik odaklı sistemlerde ACID’e daha gevşek bir alternatif olarak anılan yaklaşımdır. BASE; Basically Available, Soft State ve Eventual Consistency ifadelerinin kısaltmasıdır.
BASE yaklaşımı, sistemin her zaman güçlü anlık tutarlılık sunmak yerine yüksek erişilebilirlik ve zamanla tutarlılığa ulaşma hedefiyle çalışabileceğini kabul eder. Bu yaklaşım özellikle AP eğilimli sistemlerle ilişkilendirilir.
BASE şu fikirleri içerir:
- Basically Available: Sistem çoğu durumda cevap verebilir kalır.
- Soft State: Sistemin durumu zaman içinde arka plandaki senkronizasyonlarla değişebilir.
- Eventual Consistency: Kopyalar kısa süreli farklılık gösterse bile zamanla aynı duruma gelir.
BASE, her sistem için doğru tercih değildir. Finansal işlemler, ödeme, stok kilitleme veya kimlik doğrulama gibi alanlarda güçlü tutarlılık gerekebilir. Ancak sosyal medya sayaçları, log toplama, öneri sistemleri veya bazı analitik olaylar için eventual consistency kabul edilebilir olabilir.
Eventual Consistency Nedir?
Eventual consistency, dağıtık sistemdeki veri kopyalarının kısa süreli olarak farklı olabileceğini, ancak yeni güncelleme gelmezse zaman içinde aynı değere ulaşacağını ifade eder. Türkçede “nihai tutarlılık” olarak çevrilebilir.
Örneğin bir kullanıcı profil fotoğrafını değiştirdiğinde bazı bölgelerde yeni fotoğraf hemen görünürken, başka bölgelerde birkaç saniye eski fotoğraf görünebilir. Sistem arka planda kopyaları senkronize eder ve sonunda tüm kullanıcılar yeni fotoğrafı görür. Bu eventual consistency örneğidir.
Eventual consistency şu alanlarda kabul edilebilir olabilir:
- Sosyal medya beğeni ve takipçi sayıları
- Ürün görüntülenme sayaçları
- Bildirim sayıları
- Öneri sistemleri
- Log ve olay toplama sistemleri
- Analitik veri akışları
Ancak eventual consistency kullanıcı deneyimi ve iş mantığı açısından dikkatli yönetilmelidir. Kullanıcı farklı ekranlarda farklı bilgi görürse güven kaybı yaşayabilir. Bu nedenle eventual consistency teknik olarak doğru olsa bile ürün tasarımıyla uyumlu olmalıdır.
Strong Consistency Nedir?
Strong consistency, bir yazma işlemi tamamlandıktan sonra sonraki tüm okuma işlemlerinin bu en güncel yazmayı görmesini ifade eder. Kullanıcı hangi düğüme bağlanırsa bağlansın aynı güncel sonucu almalıdır.
Strong consistency şu durumlarda önemlidir:
- Banka bakiyesi
- Ödeme işlemleri
- Stok rezervasyonu
- Kimlik ve yetkilendirme bilgileri
- Konfigürasyon yönetimi
- Tekil kaynak tahsisi
- Hukuki veya finansal kayıtlar
Strong consistency güçlü güvence sağlar; ancak dağıtık sistemlerde gecikme ve availability maliyeti yaratabilir. Sistem, tüm kopyaların güncel olduğundan emin olmak için bekleyebilir veya ağ bölünmesi sırasında isteği reddedebilir. Bu nedenle strong consistency her veri için gerekli değildir; kritik veriler için gereklidir.
CAP Teoremi Örnekleri
Banka Bakiyesi Örneği
Bir kullanıcının hesabında 1.000 TL olduğunu düşünelim. Kullanıcı aynı anda iki farklı kanaldan 800 TL çekmeye çalışıyor. Sistem her iki işlemi de kabul ederse hesap bakiyesi negatife düşebilir. Bu durumda tutarlılık kritik önemdedir. Sistem gerekirse işlemlerden birini reddetmeli veya bekletmelidir. Bu senaryoda CP yaklaşımı daha uygundur.
Sosyal Medya Beğeni Sayısı Örneği
Bir gönderinin beğeni sayısı 1.245 yerine bazı kullanıcılara birkaç saniye 1.243 görünebilir. Bu çoğu zaman ciddi iş riski yaratmaz. Sistem erişilebilir kalmalı ve kullanıcı deneyimi kesintiye uğramamalıdır. Daha sonra sayaçlar senkronize edilebilir. Bu senaryoda AP veya eventual consistency yaklaşımı kabul edilebilir.
Alışveriş Sepeti Örneği
Alışveriş sepeti daha karmaşıktır. Kullanıcının sepete ürün eklemesi erişilebilirlik odaklı yönetilebilir. Ancak stok rezervasyonu veya ödeme aşamasında tutarlılık daha önemli hâle gelir. Bu örnek, aynı sistem içinde farklı veri yollarının farklı CAP tercihleri gerektirebileceğini gösterir.
Stok Yönetimi Örneği
Bir üründen yalnızca 1 adet kaldıysa ve iki müşteri aynı ürünü satın almak istiyorsa güçlü tutarlılık gerekir. Aksi hâlde aynı ürün iki kez satılabilir. Ancak stok gösteriminde birkaç saniyelik gecikme kabul edilebilir olabilir. Yani stok görüntüleme ile stok rezervasyonu aynı tutarlılık düzeyini gerektirmez.
Mesajlaşma Uygulaması Örneği
Mesajlaşma uygulamasında mesajın teslim edilmesi, okunma bilgisi, son görülme durumu ve çevrimiçi bilgisi farklı tutarlılık gereksinimlerine sahiptir. Mesajın kaybolmaması kritik olabilir; fakat “okundu” bilgisinin birkaç saniye geç güncellenmesi kabul edilebilir. Bu nedenle sistem parça parça tasarlanmalıdır.
CAP Teoremi ve Mikroservis Mimarisi
Mikroservis mimarisi, uygulamayı küçük ve bağımsız servisler hâline böler. Her servis kendi verisine sahip olabilir. Bu yapı esneklik ve ölçeklenebilirlik sağlar; ancak servisler arası veri tutarlılığı sorunlarını artırır.
Monolitik sistemde tek veritabanı transaction’ı ile çözülen bazı işlemler, mikroservis mimarisinde birden fazla servis arasında dağıtılır. Örneğin sipariş oluşturma, ödeme alma, stok düşme, kargo kaydı açma ve bildirim gönderme ayrı servislerde olabilir. Bu servisler arasında ağ hatası yaşanabilir. CAP gerilimi burada devreye girer.
Mikroservislerde sıklıkla şu yaklaşımlar kullanılır:
- Saga Pattern: Dağıtık transaction yerine adım adım telafi işlemleriyle süreç yönetmek.
- Eventual Consistency: Servislerin olaylar üzerinden zamanla tutarlı hâle gelmesini sağlamak.
- Outbox Pattern: Veritabanı değişikliği ile olay yayınlamayı güvenilir hâle getirmek.
- Idempotency: Aynı isteğin birden fazla kez gelmesi durumunda yanlış sonuç üretmemek.
- Retry ve Timeout Politikaları: Ağ hatalarında kontrollü yeniden deneme yapmak.
Mikroservis mimarisinde CAP Teoremi, “her şeyi anlık tutarlı yapalım” yaklaşımının maliyetini gösterir. Her servis arası işlemde güçlü tutarlılık istenirse sistem yavaşlar ve kırılganlaşır. Ancak her şeyi eventual consistency’ye bırakmak da iş kurallarını bozabilir. Doğru tasarım, işlem bazında karar vermeyi gerektirir.
CAP Teoremi ve Büyük Veri Sistemleri
Büyük veri sistemleri genellikle dağıtık mimariye dayanır. Hadoop, Cassandra, HBase, Kafka, Spark, Trino, data lake ve lakehouse gibi sistemlerde veri birden fazla düğümde, dosyada, partition’da veya region’da tutulabilir. Bu nedenle CAP düşüncesi büyük veri mimarisinde önemlidir.
Büyük veri dünyasında her işlem operasyonel transaction kadar güçlü tutarlılık gerektirmez. Analitik veriler çoğu zaman gecikmeli işlenir. Örneğin günlük satış raporu birkaç dakika gecikmeyle güncellenebilir. Log verileri toplandıktan sonra batch veya streaming süreçlerle işlenebilir. Bu tür senaryolarda availability ve ölçeklenebilirlik daha önemli olabilir.
Ancak büyük veri sistemlerinde de tutarlılık tamamen önemsiz değildir. Data lake içinde aynı veri setinin farklı sürümleri, eksik dosyalar, yarım kalmış yazma işlemleri veya hatalı partition’lar analitik sonuçları bozabilir. Bu nedenle lakehouse mimarilerinde Delta Lake, Apache Iceberg ve Apache Hudi gibi tablo formatları ACID benzeri güvenilirlik özellikleri sunmaya çalışır.
CAP Teoremi büyük veri mimarlarına şu soruyu sordurur: Hangi veri gerçek zamanlı ve tutarlı olmalı, hangi veri gecikmeli ve nihai tutarlı olabilir? Bu ayrım yapılmadan kurulan sistemler ya gereksiz pahalı ve yavaş olur ya da güvenilmez sonuçlar üretir.
CAP Teoremi ve Modern Bulut Sistemleri
Modern bulut sistemleri çok bölgeli, çok erişim noktalı ve yüksek erişilebilirlik hedefli tasarlanır. Bir uygulama aynı anda farklı availability zone’larda veya region’larda çalışabilir. Bu yapı dayanıklılık sağlar; fakat CAP gerilimini ortadan kaldırmaz.
Bulut sağlayıcıları ağ altyapısını güçlendirebilir, veri merkezleri arasında hızlı bağlantılar kurabilir, otomatik replikasyon ve failover mekanizmaları sunabilir. Ancak ağ bölünmesi ihtimali teorik ve pratik olarak tamamen yok olmaz. Bu nedenle dağıtık bulut sistemlerinde de consistency ve availability tercihleri önemlidir.
Modern sistemler çoğu zaman tek bir CAP tercihi yapmaz. Bazı veriler güçlü tutarlılıkla, bazı veriler eventual consistency ile, bazı veriler region bazlı, bazı veriler global replikasyonla yönetilir. Ayrıca quorum, lider seçimi, conflict resolution, CRDT, consensus algoritmaları ve veri bölgeleme gibi tekniklerle daha esnek tasarımlar kurulabilir.
Bu nedenle günümüzde CAP Teoremi hâlâ önemlidir; ancak tek başına yeterli sistem tasarım kılavuzu değildir. CAP, hata anındaki temel gerilimi gösterir. Gerçek sistem tasarımı ise gecikme, maliyet, kullanıcı deneyimi, veri modeli, regülasyon, coğrafi dağılım ve operasyonel karmaşıklığı da hesaba katmalıdır.
PACELC Teoremi Nedir?
PACELC, CAP Teoremi’nin sınırlılıklarını genişleten bir yaklaşımdır. PACELC şu anlama gelir: Eğer partition varsa consistency ile availability arasında tercih yapılır; partition yoksa latency ile consistency arasında tercih yapılır. İngilizce ifadesiyle: If Partition, then Availability or Consistency; Else, Latency or Consistency.
PACELC, CAP’in eksik bıraktığı önemli bir noktayı vurgular. Ağ bölünmesi olmasa bile dağıtık sistemlerde tutarlılık ve gecikme arasında gerilim vardır. Bir yazma işleminin tüm replikalara onaylatılması daha tutarlı sonuç verebilir; fakat gecikmeyi artırır. Daha hızlı cevap vermek için daha az replika beklenirse gecikme düşer; fakat tutarlılık zayıflayabilir.
Bu nedenle modern dağıtık sistemlerde tasarım yalnızca hata anına odaklanmaz. Normal çalışma sırasında da latency, throughput, consistency ve cost arasında tercih yapılır. PACELC, CAP’in daha gerçekçi bir tamamlayıcısı olarak görülebilir.
CAP Teoremi’nin Sınırları
CAP Teoremi temel bir ilke olsa da modern dağıtık sistemleri tek başına açıklamak için yeterli değildir. Bazı önemli sınırlılıkları vardır.
Fazla Basitleştirilebilir
CAP çoğu zaman “üçünden ikisini seç” diye anlatılır. Bu basitleştirme öğretici olsa da gerçek sistemleri yanlış sınıflandırmaya yol açabilir. Modern sistemler operasyon bazında farklı tutarlılık seviyeleri sunabilir.
Consistency Kavramı Dar Anlamdadır
CAP’teki consistency, ACID consistency değildir. Bu ayrım yapılmazsa kavramlar karışır. CAP daha çok okuma-yazma görünürlüğü ve linearizability ile ilgilidir.
Availability Tanımı Günlük Kullanımdan Farklıdır
CAP’te availability, çalışan her düğümün isteğe hata vermeden cevap üretmesiyle ilgilidir. Bu, sistemin kullanıcı gözündeki genel uptime metriğiyle aynı şey değildir.
Partition Dışındaki Maliyetleri Az Anlatır
CAP, ağ bölünmesi anındaki imkânsızlığa odaklanır. Normal zamanda gecikme, maliyet, throughput, veri modeli ve operasyonel karmaşıklık gibi faktörleri yeterince açıklamaz. PACELC bu boşluğu kısmen tamamlar.
Tüm Sistemi Tek Etiketle Açıklamak Zordur
Bir sistem bazı işlemlerde CP, bazı işlemlerde AP gibi davranabilir. Bu nedenle ürünleri tek kelimeyle sınıflandırmak yerine işlem bazında garanti analizi yapmak daha doğrudur.
CAP Teoremi Tasarımda Nasıl Kullanılmalı?
CAP Teoremi, sistem tasarımında karar vermek için bir düşünme aracı olarak kullanılmalıdır. Doğru kullanım, sistemi etiketlemekten çok iş gereksinimlerini anlamaya dayanır.
Bir mimar veya geliştirici şu soruları sormalıdır:
- Bu veri türü için eski veri göstermek kabul edilebilir mi?
- Ağ bölünmesi sırasında hata vermek mi daha iyi, cevap vermek mi?
- Bu işlem finansal, hukuki veya güvenlik açısından kritik mi?
- Kullanıcı deneyimi kısa süreli tutarsızlığı tolere edebilir mi?
- Veri daha sonra uzlaştırılabilir mi?
- Conflict resolution nasıl yapılacak?
- Hangi işlemler güçlü tutarlılık gerektiriyor?
- Hangi işlemler eventual consistency ile yönetilebilir?
- Gecikme, maliyet ve erişilebilirlik hedefleri nedir?
- Veri hangi coğrafi bölgelerde tutulacak?
Bu sorulara verilen cevaplar, sistemin CAP tercihlerini belirler. İyi mimari, tüm veriye aynı tutarlılık düzeyini dayatmaz. Kritik veriler için güçlü garantiler, daha toleranslı veriler için esnek modeller kullanır.
CAP Teoremi Hakkında Yanlış Anlaşılmalar
Yanlış Anlama 1: CAP Teoremi Her Zaman Üçünden İkisini Seçmektir
Bu eksik bir anlatımdır. Asıl tercih ağ bölünmesi sırasında tutarlılık ile erişilebilirlik arasında yapılır. Ağ bölünmesi yokken sistem hem tutarlı hem erişilebilir çalışabilir.
Yanlış Anlama 2: Partition Tolerance İsteğe Bağlıdır
Gerçek dağıtık sistemlerde ağ hataları kaçınılmazdır. Bu nedenle partition tolerance çoğu pratik sistemde vazgeçilmezdir. P’den vazgeçmek çoğu zaman dağıtık sistem gerçeğini yok saymak anlamına gelir.
Yanlış Anlama 3: Bir Veritabanı Tamamen CP Ya Da AP’dir
Modern sistemler farklı operasyonlar ve ayarlar için farklı davranabilir. Tek bir etiket çoğu zaman yetersizdir.
Yanlış Anlama 4: Eventual Consistency Kötüdür
Eventual consistency yanlış değildir. Doğru kullanım alanında verimli ve ölçeklenebilir bir çözümdür. Sorun, güçlü tutarlılık gereken yerde eventual consistency kullanmaktır.
Yanlış Anlama 5: Strong Consistency Her Zaman Daha İyidir
Strong consistency güven verir; fakat gecikme, maliyet ve availability bedeli olabilir. Her veri için gerekli değildir. Doğru tutarlılık düzeyi iş ihtiyacına göre belirlenmelidir.
Yanlış Anlama 6: CAP Teoremi Eski ve Geçersizdir
CAP Teoremi modern sistemleri tek başına açıklamakta yetersiz olabilir; ancak dağıtık sistemlerde ağ bölünmesi anındaki temel gerilimi hâlâ açıklar. Geçersiz değil, dikkatli yorumlanması gereken bir ilkedir.
Sık Sorulan Sorular
CAP Teoremi Ne Demek?
CAP Teoremi, dağıtık bir sistemin tutarlılık, erişilebilirlik ve ağ bölünmesine dayanıklılık özelliklerini aynı anda mutlak biçimde garanti edemeyeceğini ifade eden bilgisayar bilimi ilkesidir.
CAP Açılımı Nedir?
CAP; Consistency, Availability ve Partition Tolerance kelimelerinin baş harflerinden oluşur. Türkçede tutarlılık, erişilebilirlik ve bölünme toleransı anlamına gelir.
CAP Teoremi Neden Önemlidir?
Çünkü modern sistemler çoğu zaman dağıtık çalışır. Ağ bölünmesi yaşandığında sistemin tutarlılığı mı yoksa erişilebilirliği mi önceliklendireceği kritik bir mimari karardır.
CAP Teoremi Gerçekten “Üçünden İkisini Seç” mi Demektir?
Bu yaygın ama eksik bir anlatımdır. Daha doğru ifade şudur: Ağ bölünmesi yaşandığında sistem tutarlılık ile erişilebilirlik arasında tercih yapmak zorunda kalabilir.
Consistency Ne Anlama Gelir?
CAP bağlamında consistency, tüm okuma işlemlerinin en güncel yazmayı görmesi veya sistemin güncel veri garantisi veremediğinde hata döndürmesi anlamına gelir.
Availability Ne Anlama Gelir?
Availability, çalışan bir düğüme gelen her geçerli isteğin hata vermeden cevap almasıdır. Cevabın her zaman en güncel veri olması gerekmez.
Partition Tolerance Ne Anlama Gelir?
Partition tolerance, ağ bağlantılarında kopma, gecikme veya mesaj kaybı yaşansa bile sistemin bu duruma dayanıklı davranabilmesidir.
CP Sistem Ne Demek?
CP sistem, ağ bölünmesi durumunda tutarlılığı korumayı seçen ve gerekirse bazı isteklere cevap vermeyerek erişilebilirlikten ödün veren sistemdir.
AP Sistem Ne Demek?
AP sistem, ağ bölünmesi durumunda erişilebilir kalmayı seçen ve gerekirse kısa süreli tutarsızlıkları kabul eden sistemdir.
CA Sistem Var mıdır?
Teorik olarak consistency ve availability sağlayıp partition tolerance sağlamayan sistem CA olarak anlatılır. Ancak gerçek dağıtık sistemlerde ağ bölünmesi ihtimali olduğu için CA sınıflandırması pratikte sınırlı anlam taşır.
CAP Teoremi NoSQL için mi Geçerlidir?
Hayır. CAP Teoremi tüm dağıtık veri sistemleri için geçerlidir. Ancak NoSQL sistemleri dağıtık mimarilerde sık kullanıldığı için CAP tartışmalarında daha görünürdür.
Eventual Consistency Nedir?
Eventual consistency, dağıtık sistemdeki veri kopyalarının kısa süreli farklı olabileceğini, ancak yeni güncelleme gelmezse zamanla aynı duruma ulaşacağını ifade eder.
CAP ve ACID Aynı Şey midir?
Hayır. ACID veritabanı işlemlerinin güvenilirliğiyle ilgilidir. CAP ise dağıtık sistemlerde ağ bölünmesi durumunda tutarlılık ve erişilebilirlik arasındaki tercihleri açıklar.
PACELC Nedir?
PACELC, CAP’i genişleten bir yaklaşımdır. Partition varsa availability ile consistency arasında; partition yoksa latency ile consistency arasında tercih yapılacağını vurgular.
Sonuç
CAP Teoremi, dağıtık sistemlerin temel gerilimini açıklayan en önemli ilkelerden biridir. Modern yazılımlar giderek daha fazla sunucuya, bölgeye, veri merkezine ve bulut ortamına dağıldıkça tutarlılık, erişilebilirlik ve ağ bölünmesine dayanıklılık arasındaki ilişkiler daha kritik hâle gelir.
CAP’in asıl mesajı, “her zaman üçünden ikisini seç” gibi basit bir sloganla sınırlı değildir. Daha doğru mesaj şudur: Ağ bölünmesi yaşandığında dağıtık sistemler tutarlılık ile erişilebilirlik arasında tercih yapmak zorunda kalabilir. Bu tercih her sistem için, hatta aynı sistem içindeki her veri yolu için farklı olabilir.
Bir ödeme işlemiyle sosyal medya beğeni sayısı aynı tutarlılık düzeyini gerektirmez. Bir stok rezervasyonuyla bir bildirim sayacı aynı risk profiline sahip değildir. Bir banka bakiyesiyle ürün görüntülenme sayısı aynı mimari önceliğe sahip olamaz. CAP Teoremi, bu farkları düşünmek için güçlü bir çerçeve sunar.
Ancak CAP Teoremi tek başına modern dağıtık sistem tasarımının tamamını açıklamaz. Gecikme, maliyet, kullanıcı deneyimi, veri modeli, regülasyon, coğrafi dağıtım, conflict resolution, gözlemlenebilirlik ve operasyonel karmaşıklık gibi faktörler de hesaba katılmalıdır. PACELC gibi yaklaşımlar CAP’in bu sınırlılıklarını tamamlar.
Sonuç olarak CAP Teoremi, dağıtık sistemlerde imkânsız olanı değil, bilinçli tercih yapılması gereken alanı gösterir. İyi sistem tasarımı, tüm veriler için tek bir tutarlılık modeli seçmek değil; her iş süreci için doğru tutarlılık, erişilebilirlik ve hata toleransı dengesini kurmaktır. CAP Teoremi’nin gerçek değeri, bu dengeyi görünür kılmasında yatar.
Kaynakça
- Abadi, D. J. (2012). Consistency tradeoffs in modern distributed database system design: CAP is only part of the story. Computer, 45(2), 37-42.
- Amazon Web Services. (2026). CAP theorem. AWS Availability and Beyond Whitepaper.
- Brewer, E. A. (2000). Towards robust distributed systems. Proceedings of the ACM Symposium on Principles of Distributed Computing.
- Brewer, E. A. (2012). CAP twelve years later: How the “rules” have changed. Computer, 45(2), 23-29.
- Cattell, R. (2011). Scalable SQL and NoSQL data stores. ACM SIGMOD Record, 39(4), 12-27.
- DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., & Vogels, W. (2007). Dynamo: Amazon’s highly available key-value store. Proceedings of Twenty-First ACM SIGOPS Symposium on Operating Systems Principles, 205-220.
- Gilbert, S., & Lynch, N. (2002). Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, 33(2), 51-59.
- IBM. (2026). What is the CAP theorem? IBM Think.
- Kleppmann, M. (2015). A critique of the CAP theorem. arXiv.
- Kleppmann, M. (2017). Designing data-intensive applications. O’Reilly Media.
- Lakshman, A., & Malik, P. (2010). Cassandra: A decentralized structured storage system. ACM SIGOPS Operating Systems Review, 44(2), 35-40.
- Vogels, W. (2009). Eventually consistent. Communications of the ACM, 52(1), 40-44.
İlave Okuma Önerileri
- Bailis, P., & Ghodsi, A. (2013). Eventual consistency today: Limitations, extensions, and beyond. Communications of the ACM, 56(5), 55-63.
- Carpenter, J., & Hewitt, E. (2016). Cassandra: The definitive guide (2nd ed.). O’Reilly Media.
- Coulouris, G., Dollimore, J., Kindberg, T., & Blair, G. (2011). Distributed systems: Concepts and design (5th ed.). Addison-Wesley.
- Fowler, M., & Sadalage, P. J. (2012). NoSQL distilled: A brief guide to the emerging world of polyglot persistence. Addison-Wesley.
- Hellerstein, J. M., & Alvaro, P. (2020). Keeping CALM: When distributed consistency is easy. Communications of the ACM, 63(9), 72-81.
- Howard, H., Malkhi, D., & Spiegelman, A. (2016). Flexible Paxos: Quorum intersection revisited. arXiv.
- Lamport, L. (1998). The part-time parliament. ACM Transactions on Computer Systems, 16(2), 133-169.
- Ongaro, D., & Ousterhout, J. (2014). In search of an understandable consensus algorithm. USENIX Annual Technical Conference, 305-319.
- Tanenbaum, A. S., & Van Steen, M. (2017). Distributed systems (3rd ed.). Maarten van Steen.
- White, T. (2015). Hadoop: The definitive guide (4th ed.). O’Reilly Media.
🗓️ Yayınlanma Tarihi: 10 Haziran 2026
🔄 Son Güncelleme Tarihi: 10 Haziran 2026
🎯 Kimler için: Bu yazı, CAP Teoremi, dağıtık sistemler, NoSQL, büyük veri, mikroservis mimarisi, veri tabanları, cloud computing, sistem tasarımı, availability, consistency, partition tolerance ve modern veri mimarisi konularıyla ilgilenen okurlar için hazırlanmıştır. Ayrıca yazılım geliştiriciler, veri mühendisleri, sistem mimarları, DevOps mühendisleri, SRE ekipleri, teknoloji yöneticileri, öğrenciler ve dağıtık veritabanlarının nasıl çalıştığını anlamak isteyen herkes için temel bir başvuru metni olarak tasarlanmıştır.
İçerik Bilgisi
Invictus Wiki editoryal ekibini temsil eden kolektif bir yazarlık imzasıdır. IW imzasıyla yayımlanan içerikler; çok kaynaklı araştırma, editoryal inceleme ve tarafsızlık ilkeleri doğrultusunda hazırlanır.
