> MİMARİ KATALOĞU // SÜRÜM 1.0
18 Dağıtık Sistem Referans Mimarisi
54 Olgunluk Konfigürasyonu, CAP/PACELC Ödünleşimleri, Sıfır-Kayıp Garantileri ve Üretim Terraform Manifestoları
Reaktif Akış Talep-Güdümlü (Backpressure) Akış İşlemcisi
Dinamik talep sinyalleri ileterek bellek tamponlarının taşmasını önleyen, Reactive Streams standardını uygulayan çekme-tabanlı (pull-based) reaktif akış işlemcisi.
Dinamik Eşzamanlılık & Uç Gecikme Önleyici (Load Shedder)
Trafiği dinamik olarak sınırlamak ve uç gecikme patlamalarını engellemek için TCP Vegas ve gradyan algoritmalarını kullanan otonom yük atma mimarisi.
Çok-Katmanlı Dağıtık Hız Sınırlayıcı (Token Bucket & Sliding Window)
Çok-kiracılı kotaları milisaniye-altı ek yükle zorunlu kılmak için yerel bellek token bucketlarını Redis kayan-pencere log koordinasyonuyla birleştiren hız sınırlayıcı.
CAP, PACELC, Raft ve Reaktif Akış standartlarında yüksek verimli dağıtık sistemler kanonu: Dual-write riskini Transactional Outbox ile önleyin, zombi liderleri fencing belirteçleriyle engelleyin ve çekme-tabanlı backpressure ile OOM çökmelerini durdurun.
Dağıtık Sistem Mimarisi Sıkça Sorulan Sorular
Linearizability ile Serializability arasındaki temel matematiksel fark nedir?
Serializability çok-işlemli, çok-nesneli bir işlemsel (transactional) güvencedir: eşzamanlı çalışan işlemler grubunun herhangi bir geçerli ardışık sırada çalışmış gibi görünmesini garanti eder ancak gerçek zamanlı duvar saati sıralaması hakkında bir şey söylemez. Linearizability (atomik tutarlılık) ise tek-işlemli, tek-nesneli gerçek zamanlı bir güvencedir: bir işlem gerçek fiziksel zamanda tamamlandığı anda, sonrasında başlayan tüm işlemler küresel olarak o yeni değeri veya daha yenisini görmek zorundadır. Her iki özelliği birden sağlayan sistemlere "Strict Serializable" veya "External Consistent" denir (örn. Google Cloud Spanner).
Transactional Outbox deseni dual-write mutasyon kaymasını matematiksel olarak nasıl ortadan kaldırır?
Basit dual-write anti-pattern’i, uygulama kodunda önce RDBMS güncellemesi yapıp ardından Kafka’ya mesaj göndermeye çalışır. Adımlardan biri çökerse veya zaman aşımına uğrarsa sistem kalıcı olarak tutarsızlaşır. Transactional Outbox deseni, dışarıya gidecek olayı iş varlığıyla TAM OLARAK AYNI yerel veritabanı işleminde (transaction) bir `outbox_events` tablosuna yazar. Atomiklik yerel RDBMS ACID özellikleri ile garanti edilir. Ayrı bir Change Data Capture (CDC) motoru (örn. Debezium), veritabanının Write-Ahead Log (WAL) dosyasını okuyarak olayları en az bir kez teslimat (at-least-once) güvencesiyle Kafka’ya aktarır.
Bir mimari ne zaman RabbitMQ veya NATS JetStream yerine Apache Kafka seçmelidir?
Yeniden oynatılabilir (replayable) kalıcı bir commit loguna, yüksek bölümleme verimliliğine (>100k msg/sn), uzun süreli saklamaya (katmanlı depolama ile sonsuz), tüketici gruplarının geçmişi baştan okuyabilmesine ve bölüm anahtarı başına katı toplam sıralamaya ihtiyaç duyduğunuzda Apache Kafka seçin. Karmaşık AMQP dinamik yönlendirmesi, ayrıntılı işçi kuyruğu paylaşımı ve öncelikli mesajlaşma gerekiyorsa RabbitMQ tercih edin. Milisaniye-altı gecikme, hafif operasyonel yük (tek binary), sıfır JVM maliyeti ve uç/IoT pub/sub için ise NATS JetStream seçin.
Raft nasıl uzlaşma sağlar ve ağ bölünmelerinde split-brain durumunu nasıl kesinlikle engeller?
Raft güvenliği çoğunluk quorumu ($Q = \lfloor N/2 \rfloor + 1$) ile sağlar. Tek sayılı bir kümede (örn. 5 düğüm), herhangi iki 3 düğümlük çoğunluk en az bir ortak düğümde KESİŞMEK ZORUNDADIR. Ağ bölünmesi kümeyi 3 ve 2 düğüm olarak ikiye ayırırsa, yalnızca 3 düğümlük taraf çoğunluğu toplayarak lider seçebilir ve log işleyebilir. 2 düğümlük azınlık tarafı quorum sağlayamaz ($2 < 3$) ve tüm yazma isteklerini reddeder. Ayrıca katı artan dönem (term) numaraları, eski dönemden kalan bir zombi liderin daha yüksek dönemli bir düğümle temas ettiğinde anında liderlikten düşürülmesini sağlar.
Üretim ortamlarında Saga Orkestrasyonu neden Saga Koreografisine göre daha güvenilir ölçeklenir?
Saga Koreografisinde mikroservisler etki alanı olaylarını dinler ve bağımsız olarak yeni olaylar fırlatmaya veya telafi yapmaya karar verir. İş akışı 4 servisi aştığında koreografi; görünmez döngüsel olay kilitlenmelerine, karmaşık dağıtık duruma, imkansız adli gözlemlenebilirliğe ve servis çöktüğünde telafi adımlarının yarım kalmasına yol açar. Saga Orkestrasyonu (Temporal.io veya Cadence kullanarak) iş akışı koordinasyonunu dayanıklı bir durum makinesinde merkezileştirir: orkestratör servisleri doğrudan komuta eder, zaman aşımlarını izler, hata anında telafi işlemlerini deterministik olarak çalıştırır ve yürütme geçmişini düğüm çökmelerine karşı korur.
Çakışmasız Veri Tipleri (CRDT), dağıtık kilitler olmadan çok-merkezli yakınsamayı nasıl başarır?
CRDT’ler soyut cebire dayanır: mutasyonlar, üç matematiksel kuralı sağlayan bir birleştirme operatörüne ($\sqcup$) sahip yarı-örgüler (join-semilattice) olarak modellenir: Değişme Özelliği ($A \sqcup B = B \sqcup A$), Birleşme Özelliği ($(A \sqcup B) \sqcup C = A \sqcup (B \sqcup C)$) ve İdempotency ($A \sqcup A = A$). Durum güncellemelerini uygulama sırası veya tekrar sayısı nihai sonucu değiştirmediği için, çok-bölgeli kopyalar yazma isteklerini sıfır koordinasyon gecikmesiyle yerel olarak kabul edebilir, güncellemeleri asenkron takas edebilir ve tüm güncellemeler ulaştığında matematiksel olarak kesinlikle aynı duruma yakınsar.