CAP Theorem: Okyanusun Altındaki Kablo Koptuğunda Ne Seçersiniz?

⚡ Hızlı Özet

CAP theorem, dağıtık sistemlerde Consistency, Availability ve Partition Tolerance üçgenini tanımlar.
Partition Tolerance bir seçim değildir; fiziksel bir gerçektir. Ağ er ya da geç bölünür.
Gerçek karar tek bir soruya iner: Bağlantı koptuğunda yanlış veri mi göstereyim, yoksa sistemi kapayayım mı?
Bankalar veriyi korumak için sistemi kapatır (CP). Sosyal medya platformları geçici tutarsızlığı kabul eder (AP).
Bu kararı kriz anında değil, mimari tasarım aşamasında vermeniz gerekir.

Okyanusun binlerce metre altında, kıtalar arası trafiği taşıyan kalın bir fiber optik kablo düşünün. O kablo bir gün koptuğunda — fiziksel bir kesim, bir kazı hatası, olağandışı bir okyanus akıntısı — arka planda çalışan sistemleriniz anında bir çıkmazla yüz yüze gelir. Kullanıcılara hatalı veri mı göstereyim? Yoksa sistemi erişime tamamen kapatayım mı?

Bu ikilem, CAP theorem’i anlamanın tam merkezindedir. Ve cevabı önceden vermemişseniz, sisteminiz bu kararı sizin yerinize verir.

“İstediğiniz İkisini Seçin” Yanılgısı

CAP theorem, 2000 yılında Eric Brewer tarafından ortaya atıldı ve 2002’de Gilbert-Lynch kanıtıyla formalize edildi. Teorem şunu söyler: bir dağıtık sistem, ağ bölünmesi (Partition) durumunda aynı anda hem Consistency hem de Availability garantisini veremez.

Çoğu yazılımcı bunu “üçten iki seç” kuralı olarak öğrenir. Bu açıklama teknik olarak doğru ama pratikte yanıltıcıdır. Çünkü Partition Tolerance seçilebilir bir özellik değildir. Ağlar bölünür. Bu, fiziğin sınırıdır. Birden fazla sunucu çalıştıran her sistem, günün birinde bir network partition yaşayacaktır.

Gerçek seçim şu: Partition anında C mi, A mı?

Consistency’yi seçerseniz sistemin tutarlılığını korursunuz, fakat o an yanıt veremeyebilir. Availability’yi seçerseniz sistem her zaman yanıt verir, fakat bazı yanıtlar güncel olmayabilir.

Ne seçeceğinizi belirleyen şey teknoloji değildir. İş modelinizin doğasıdır.

Banka, Sosyal Medyayla Aynı Kodu Çalıştıramaz

Bir banka hesabını düşünün. New York’taki sunucunuza 100 dolar yatırdınız. Ağ tam o anda ikiye bölündü. Londra sunucusu bu güncellemeyi göremedi. Bir saniye sonra aynı hesaptan Londra üzerinden ödeme çekilmeye çalışıyor. Londra sunucusu bakiyeyi sıfır görüyor.

Eğer sistem o noktada Availability’yi seçip yanıt verirse, var olmayan para çekilmiş olur.

Bankalar bu yüzden Consistency tarafını seçer. İşlem gerçekleşemiyorsa HTTP 500 döner. Kullanıcı “şu an hizmet veremiyoruz” ekranını görür. Para kaybı önlenir. Bu pahalı bir karardır — sistem kapalı görünür — ama için doğru olandır. PostgreSQL ve benzeri ilişkisel veritabanları bu yüzden finansal sistemlerin standart altyapısı olmuştur.

Şimdi bir sosyal medya platformunu düşünün. İki kullanıcı aynı anda aynı gönderiye yorum yapıyor. Sunucular bölünmüş durumda. Her sunucu kendi yorumunu yazıyor ama karşı tarafa iletemiyor. Sonuç: iki farklı yorum listesi, iki farklı gerçeklik.

Ağ onarıldığında sistem bu iki versiyonu birleştirir. Birkaç saniyeliğine farklı kullanıcılar farklı yorum listeleri görmüş olur. Bu durumun hayati bir riski yoktur. Yeter ki kullanıcı “uygulama çöktü” sanıp uygulamayı kapatmasın.

Sosyal medya, anlık mesajlaşma ve içerik servisleri bu yüzden Availability’yi seçer.

Cassandra ve benzeri NoSQL veritabanları, bu eventual consistency modelini desteklemek için tasarlanmıştır.

Gerçekte Ne Olur?

Bu durum teorik değildir. Temmuz 2024’te Amazon Kinesis Data Streams, us-east-1 bölgesinde yaklaşık yedi saat boyunca kesintiye uğradı. Yalnızca Kinesis değil — bu servise bağımlı düzinelerce AWS bileşeni birlikte etkilendi. (Kaynak: AWS Post-Event Summary, Temmuz 2024)

Bu olay, bulut altyapısının ne kadar bölünebilir olduğunu gösteriyor. Tek bir iç bileşenin arızası, tam bir Partition durumu yaratabilir. O gün hangi veritabanı tercihini yapmış olduğunuza göre, bazı sistemler graceful bir hata verdi, bazıları ise planlanmamış tutarsızlıklar üretti.

Kendi sistemlerinizide aynı senaryo geçerliadir. Bir cloud availability zone bir dakikalığına düşse bile, veritabanınız ikiye bölünmüş olur. O an önceden bir karar vermediyseniz, sistem bu kararı sizin yerinize — ve büyük olasılıkla yanlış — verir.

Mühendisler İçin Ne Anlama Geliyor?

CAP theorem bir veritabanı konfigürasyonu değildir. Bir iş kararıdır.

Sisteminizi tasarlarken şu soruyu sorun: Partition anında kullanıcının karşılaştığı en kötü senaryo hangisi daha az zararlı — yanlış veri mi, yoksa erişim hatası mı?

Para, hisse senedi, sağlık verisi içeren sistemler için cevap neredeyse her zaman Consistency yönündedir. Kullanıcı birkaç saniyeliğine hata görür ama veri bütünlüğü korunur.

Sosyal etkileşim, içerik, bildirim, öneri sistemleri için cevap genellikle Availability yönündedir. Geçici tutarsızlık, tam erişim kesilmesinden çok daha az zararlıdır.

Bu karar mimari tasarım aşamasında, ekiple birlikte, iş gereksinimleri ortada açıkken verilmelidir. Üretim ortamında ağ bölündükten sonra değil.

İlgili Yazılar

Sık Sorulan Sorular

CAP theorem nedir, kısaca açıklar mısınız? +

CAP theorem, bir dağıtık sistemin ağ bölünmesi (Partition) durumunda aynı anda hem Consistency hem de Availability garantisini veremeyeceğini söyler. Partition Tolerance seçilebilir bir özellik değildir, fiziksel bir zorunluluktur. Gerçek tercih Consistency ile Availability arasındadır.

CAP theorem’de “iki seç” kuralı neden yanıltıcıdır? +

Üçten iki seç ifadesi teknik olarak doğrudur ama pratik anlamda yanıltıcıdır. Partition Tolerance, birden fazla sunucu çalıştıran her sistemde er ya da geç karşılaşılan bir olgudur. Onu seçmemek mümkün değildir. Gerçek karar sadece Consistency ile Availability arasında şekillenir.

CP sistem nedir, ne zaman tercih edilir? +

CP sistemler, ağ bölünmesi sırasında bazı istekler yanıtsız kalsa bile veri tutarlılığını korur. Bankalar, ödeme işlemcileri, borsalar ve sağlık kayıt sistemleri bu modeli tercih eder. Yanlış veri, geçici erişim kesilmesinden çok daha yüksek riske yol açar. PostgreSQL bu modelin yaygın temsilcisidir.

AP sistem nedir, ne zaman tercih edilir? +

AP sistemler, ağ bölünmesi sırasında bile her isteğe yanıt verir. Fakat bazı yanıtlar güncel olmayabilir — buna eventual consistency denir. Sosyal medya platformları, içerik servisleri ve anlık mesajlaşma uygulamaları bu modeli tercih eder. Cassandra ve DynamoDB bu yaklaşım için tasarlanmıştır.

Eventual consistency ne demektir? +

Eventual consistency, bir veri değişikliğinin tüm sunuculara anlık değil kademeli olarak yayılacağını garanti eder. Ağ onarıldıktan sonra tüm kopyalar tutarlı bir sonuca ulaşır. Bu süre zarfında farklı kullanıcılar geçici olarak farklı veriler görebilir. Sosyal medyadaki beğeni sayısının anlık farklılık göstermesi buna iyi bir örnektir.

Bir network partition gerçek hayatta nasıl gerçekleşir? +

Kablo kesintileri, veri merkezi güç arızaları, switch hataları veya cloud provider availability zone’larının geçici olarak düşmesi network partition yaratabilir. Temmuz 2024’te AWS us-east-1’de yaşanan yaklaşık yedi saatlik Kinesis kesintisi, tek bir bileşen arızasının nasıl geniş çaplı partition etkisi yaratabileceğini somut olarak göstermiştir.

CAP theorem sistemi tasarlarken beni nasıl yönlendirmelidir? +

Sisteminizin hangi hatayla daha iyi başa çıkabileceğini sorun: yanlış veri mi, yoksa geçici erişim hatası mı? Cevap hangi tarafta durmanız gerektiğini belirler. Bu kararı üretim ortamında değil, mimari tasarım aşamasında iş gereksinimleri açıkken verin. Veritabanı seçiminiz bu kararın teknik yansımasıdır.