CAP Teorisi: Bir Sistem Neden Aynı Anda Her Şeyi Başaramaz?

“Dağıtık sistemlerde aynı anda Tutarlılık (Consistency), Erişilebilirlik (Availability) ve Bölünmeye Dayanıklılık (Partition Tolerance) üçlüsünün tamamını kusursuz sağlamak mümkün değil.” Kulağa akademik geliyor ama derdi çok insani: kopukluk olduğunda neyi feda edeceğiz?

Bu yazıda CAP’i kafede sıra bekleyen müşteriler, e-ticaret sepeti, banka havalesi, sosyal medya gönderileri gibi gerçek örneklerle konuşacağız. Ayrıca PACELC kuralı, CP vs AP tercihleri, mülakatta nasıl anlatılır ve mimari tasarım kararları ile bitireceğiz.

1) CAP’in Üç Ayağı (C, A, P) — Basit, Net Tanımlar

• C — Consistency (Tutarlılık) Aynı anda okuyan herkes aynı veriyi görür. Banka bakiyesi örneği: Para çıkışı yapıldıysa başka cihazda da anında düşmüş görünmeli.
• A — Availability (Erişilebilirlik) Sistem cevap verir (boş dönmez, time-out’a boğmaz). Instagram örneği: Yoğunlukta bile “gönderini aldım” diyebilmeli.
• P — Partition Tolerance (Bölünmeye Dayanıklılık) Ağ kopukluğu yaşansa bile sistem bir şekilde çalışmaya devam eder. Mikroservis örneği: Bir bölgede network koptu diye tüm dünya hizmet dışı kalmasın.

Kritik cümle: Dağıtık sistemlerde P şarttır (ağ kopukluğu olur). Dolayısıyla pratikte karar hep C ↔ A arasında verilir: Kopukluk anında tutarlılığı mı yoksa erişilebilirliği mi tercih edeceksin?

2) “Üçü Bir Arada” Neden Olmuyor?

Çünkü kopukluk olduğunda iki düğüm birbirinden habersiz kalır.

• “Mutlaka aynı veriyi göstersin” dersen bazen cevap veremezsin (erişilebilirlikten ödün).
• “Mutlaka cevap verelim” dersen bazı anlarda farklı doğrular oluşur (tutarlılıktan ödün, sonra uzlaşırsın).

Kafedeki benzetme:

• C: Herkese aynı sipariş bilgisini göstermek için baristanın tek defterine bağlı kalırsın. Kopukluk olursa sırada bekletirsin.
• A: “Herkesi gönderelim” dersen defter bölündüğünde geçici karışıklık olur; sonra defterleri birleştirip uzlaşırsın.
• P: Defterler ikiye bölünse de kafe işlesin istersin.

3) Üç Köşe, Üç Yol: CA / CP / AP

• CA (Consistency + Availability)Gerçek bir dağıtık bölünme varsaymaz (tek düğüm ya da güçlü tek-merkez). Network bölünmesi olduğunda sürdürülemez. Küçük/tek node RDBMS gibi düşün; bölünme yaşanırsa bu ideal bozulur.
• CP (Consistency + Partition Tolerance) Kopukluk anında tutarlılığı korur, erişimi kısar.

  Örnek: Birincil node erişilemiyorsa yazmaları bloklar (ya da quorum bekler).

  Kullanım: Banka, borsa emir defteri, stokta “eksiye” düşmek istemeyen kritik senaryolar.

• AP (Availability + Partition Tolerance) Kopukluk anında erişimi sürdürür, tutarlılığı sonra toparlar (eventual consistency).

  Örnek: Sosyal medya beğeni sayısı, ürün yorumları, timeline akışı.

  Kullanım: Okumanın çok, yazmanın bol olduğu; gecikmenin kritik olduğu sistemler.

4) Gerçek Hayattan 4 Senaryo

4.1 Banka Havalesi (CP tercihinin klasiği)

• İki bölgeli veri merkezi arasında network koptu.
• Sen havale talimatı verdin.
• CP sistem “para iki kez yazılmasın” diye yazmayı bloklayabilir ya da quorum bekler.
• Sonuç: Bazen “işleminiz sıraya alındı” gibi gecikme olur ama bakiyeler tutarlıdır.

4.2 E-Ticaret Sepeti (AP rahatlığı)

• Sepete ürün atıyorsun; network hafif sallandı.
• AP sistem işlemi kabul eder, sonra stok/limit ile uzlaşır.
• Sonuç: “Sepete eklendi” hızlıdır ama nadiren “ürün tükendi, sepetinden çıkardık” diyebilir.
• Kullanıcı deneyimi akıcıdır; tutarlılık sonradan toplanır.

4.3 Sosyal Medya Beğenileri (AP; eventual consistency)

• Beğeni sayısı herkes için hemen artabilir (erişilebilirlik yüksek).
• Fakat anlık sayılar kişi kişi ufak farklı görünebilir.
• Birkaç saniye/çok kısa sürede uzlaşır ve eşitlenir.

4.4 Stok Yönetimi (CP eğilimi)

• Kritik parça stoğu 1.
• İki region aynı anda “sipariş verildi” diyor.
• CP tasarım ikinci yazmayı durdurur/erteleme getirir, çift harcamayı engeller.

5) CAP’i Güncelleyen Bakış: PACELC Kuralı

CAP sadece kopukluk (Partition) varken kararını söyler. PACELC, “kopukluk yoksa bile” şunu sorar:

PA: Partition varsa C mi A mı?

ELC: Else (kopukluk yoksa) Latency mi Consistency mi?

Yani günlük hayatta kopukluk yokken bile “daha düşük gecikme mi, daha güçlü tutarlılık mı?” seçimi yaparsın.

• EL (Low Latency): Örn. coğrafi olarak yakın okuma kopyaları, cache.
• EC (Consistency): Örn. global doğruluk isteyen işlemler (finansal denge).

6) Mimari Kararları Nasıl Etkiler?

6.1 Replica / Majority (Quorum) Yazma

• CP tarafı: Yazmayı majority onayıyla kabul et; azınlık kopyalar kopuksa beklet.
• AP tarafı: Yazmayı hemen kabul et; background’da replike et, çatışmayı sonradan çöz.

6.2 Conflict Resolution (Çatışma Çözümü)

• Last-Write-Wins (LWW): Zaman damgası büyük olan kazanır (basit ama veri kaybı riski).
• CRDT’ler: Matematiksel olarak birleştirilebilir veri tipleri (counter, set) — AP sistemlerde harika.
• App-level Merge: Domain kurallarınla birleştir (örn. “en yüksek versiyon + audit kaydı”).

6.3 Okuma/Yazma Ayrıştırması

• CQRS: Okumayı ve yazmayı böl; okumalara AP yaklaşımı, yazmalara CP yaklaşımı uygulayabilirsin.
• Örn: Okumalar cache + read replica (hızlı), yazmalar quorum (güvenli).

6.4 Mesajlaşma (Kafka/RabbitMQ)

• At-least-once teslimat AP ruhuna yakın (erişilebilirlik > çift işleme riski; idempotency lazım).
• Exactly-once semantik CP’ye gün yakındır; çoğu sistemde idempotent tüketim + outbox ile pratik çözüm.

7) “Mülakatta CAP’i Nasıl Anlatırım?”

Kısa, akılda kalıcı cevap:

“CAP’e göre dağıtık sistemlerde ağ bölünmesi kaçınılmazdır. Bölünme olduğunda tutarlılık © ile erişilebilirlik (A) arasında seçim yapmak zorunda kalırız. Finansal işlemlerde genelde CP, sosyal akışlarda AP seçilir. Günlükte ise PACELC kuralı bize kopukluk yokken dahi gecikme ve tutarlılık arasında denge kurmamızı hatırlatır.”

Takip cümlesi (örnekle):

“E-ticarette sepeti AP yapıp kullanıcı deneyimini akıcı tutuyorum; ödeme adımında CP’ye geçip tutarlılığı garanti ediyorum.”

8) Sık Yapılan Hatalar / Yanlış Anlamalar

• “Üçü de mümkün, yeterince node ekleriz.” → Hayır. Kopukluk anında doğa kanunu gibi seçim yapacaksın.
• “AP sistemler güvensiz.” → Değil. Doğru idempotency, audit, çatışma çözümü ile güvenli ve ölçekli.
• “CP her zaman daha iyidir.” → Değil. Kullanıcı deneyimini gereksiz yere boğabilir, kapasiteyi törpüler.

) Mini Rehber: Hangi Durumda CP, Hangi Durumda AP?

CP’yi seç (erişim pahasına doğruluk):

• Para transferi, borsa emir defteri
• Envanter/lot takibi (negatif stoğa asla izin verilmiyorsa)/li>
• Yetkilendirme/izin değişikliği (ACL) gibi güvenlik-kritik yazmalar

AP’yi seç (doğruluk pahasına erişim/hız):

• Timeline/akış, beğeni sayısı, yorumlar
• Log toplama, analitik event akışı
• İçerik arama, öneri motorları (yakın gerçek zamanlı uyum yeterliyse)

Hibrit yap (en pragmatiği):

AP + CP birlikte: Akış AP, ödeme CP; sepet AP, stok CP; okuma AP, yazma CP.

10) Uçtan Uca Örnek: “E-Ticaretin 5 Adımı”

• 1. Katalog/Arama (AP + Cache) Ultra hızlı listeleme, yakın gerçek zamanlı güncelleme.
• 2. Sepet (AP) Hemen kabul; stokla sonradan uzlaşma.
• 3. Ödeme (CP) Idempotent token + quorum; iki kez çekimi engelle.
• 4. Sipariş Olayları (AP + Idempotency) Outbox + tüketicide idempotent işlem.
• 5. Raporlama (AP) Eventual konsolidasyon; tutarlılık raporlama katmanında.