CAP Teoremi: Dağıtık Sistemlerin "Üç Yol" Seçimi

"Üçünü birden alamazsın"

Modern dünyada her veritabanı, her uygulama dağıtık çalışır. Bu sistemler için Brewer (Eric Brewer, 2000) teoremi — sonra Gilbert ve Lynch 2002'de ispatladı:

Bir dağıtık veri sistemi şu üç özelliğin en fazla ikisine sahip olabilir:

• C (Consistency): herkes aynı veriyi görür.
• A (Availability): her istek cevap alır.
• P (Partition tolerance): ağ kopmalarına dayanır.

Üç özellik

Consistency

Tüm node'lar aynı anda aynı veriyi gösterir. Bir yazma operasyonu sonrası tüm okumalar yeni değeri döner.

Availability

Sistem her zaman cevap verir. Bazı node'lar düşse de geri kalan çalışır.

Partition tolerance

Ağ kopması (network partition) olsa da sistem çalışmaya devam eder.

Neden trade-off?

Network partition mutlaka olur — bu kaçınılmaz. Yani P her zaman gereklidir.

O halde gerçek seçim: CP mi, AP mi?

CP sistemler

Partition olduğunda bazı isteklere cevap verme — tutarlılığı koru.

Örnek: bankada para çekme sırasında ağ kopması olursa işlemi reddet, çift harcama önle.

AP sistemler

Partition olduğunda eski veriyle cevap ver — kullanılabilirliği koru.

Örnek: e-ticaret stok sayısında biraz eski sayı kabul edilebilir.

CA sistemler?

Genelde mümkün değildir çünkü P olmadan dağıtık değildir. Tek makine veritabanı CA olabilir (örn. SQLite).

Pratik veritabanı kategorisi

Sistem	Kategori
MySQL master-slave	CP
PostgreSQL	CP
MongoDB (varsayılan)	CP
Cassandra	AP
DynamoDB	AP
Riak	AP
Spanner	CP (özel: TrueTime)
Etcd, Consul	CP
Redis cluster	AP (varsayılan)

Eric Brewer ve teorem

Eric Brewer UC Berkeley profesörü, 2000 PODC konferansında fısıltılı not olarak sundu. Resmi makale değil.

2002: Seth Gilbert ve Nancy Lynch MIT'de resmi ispat.

2012: Brewer ünlü makale "CAP Twelve Years Later" — teoremi revize etti.

PACELC: CAP'ın genişletmesi

Yusuf Abadi 2010'da PACELC önerdi: CAP yetersiz.

Partition varsa: A vs C.
Else (partition yok): Latency vs Consistency.

Yani her zaman trade-off: ya gecikme ya tutarlılık.

Modern veritabanları PACELC'ye göre değerlendirilir.

ACID vs BASE

İki farklı yaklaşım:

ACID

• Atomic, Consistent, Isolated, Durable.
• Klasik SQL.
• CP ailesi.

BASE

• Basically Available, Soft state, Eventually consistent.
• NoSQL.
• AP ailesi.

Modern AI sistemleri için

Vector DB seçimi:

• Pinecone: AP, yüksek availability.
• Weaviate: CP varyantları.
• Qdrant: yapılandırılabilir.

LLM serving:

• Yük dengeleme + cache: AP eğilimli.
• Reasoning cache: tutarlılık önemli, CP.

Türk endüstri örnekleri

• Bankacılık: CP zorunlu. Para işlemleri eski veriyle yapılamaz.
• E-ticaret stok: AP genelde, bazen CP (kritik ürün).
• Sosyal medya feed: AP — biraz eski güncelleme tolere edilir.
• Devlet hizmetleri: CP — vergi, tapu işlemleri.

CockroachDB, YugabyteDB

Modern CP veritabanları distributed SQL sözü verir:

• Spanner'dan ilham.
• ACID + dağıtım.
• Açık kaynak.

Türk fintek startuplarının baskın seçimi.

Sık yapılan hatalar

"CAP'ı yanlış anlamış"

Brewer kendisi 2012'de: "CAP iki seçim değil, tüm trade-off uzayında nerede konumlanıyorsun" demek.

"P'yi feda et"

P kaçınılmaz; feda edilemez.

"Birden fazla 9"

"%99.99 uptime" promosyonu CAP'tan bağımsız bir konu; CAP teorik sınır.

Felsefe

CAP teoremi fizik yasası gibi: dağıtık sistemlerin uçurum sınırı.

Brewer: "Mühendislik trade-off yönetmektir, ideal aramak değil."

Kapanış

CAP teoremi modern bulutun felsefi temeli. Hangi veritabanını seçmen gerektiğini, sistem tasarımının ödünlerini bilmek için şart bilgi.

Bir yazılım mühendisinin olgunluk işareti: "Bu sistem CP mi AP mi?" sorusunu sorabilmek.