> 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ı
Ultra Yüksek Verimli KRaft Olay Ağı (Event Mesh)
Kafka Raft (KRaft) metaveri quorumu, katmanlı uzak bulut depolama ve bölüm seviyesinde idempotency ile güçlendirilmiş ZooKeeper’sız kurumsal olay akış ağı.
Donanım Optimize Thread-per-Core C++ Akış Hattı
Deterministik milisaniye-altı p99 gecikmeleri için Linux io_uring ve Seastar mimarisinden yararlanan sıfır-JVM, çekirdek-başına-iş-parçacıklı C++ olay akış platformu.
Çok-Kiracılı Katmanlı Depolama Olay Akışı (Apache Pulsar)
Sonsuz saklama ve milyonlarca konu için Apache Pulsar brokerları ve Apache BookKeeper ledgerlarını ayıran ayrık hesaplama-ve-depolama mimarisi.
Raft Tabanlı Kümeli Durum Makinesi
Pre-Vote doğrulaması, log sıkıştırma snapshotları ve lineerleştirilebilir okuma kiraları ile Raft protokolünü uygulayan resmi kanıtlı uzlaşma durum makinesi.
Yüksek Erişilebilirlikli Dağıtık Kilit & Lider Seçim Ağı
Artan fencing belirteçleri, kalp atışı kira (lease) tazelemesi ve gRPC izleme akışları uygulayan hata-toleranslı dağıtık kilit ve koordinasyon sistemi.
TrueClock-Senkronize Küresel Dağıtık Veritabanı
Atomik saatler ve Multi-Paxos uzlaşması kullanarak kıtalar arasında Harici Tutarlılık (katı serializability) sağlayan küresel dağıtık ilişkisel veritabanı.
Append-Only Olay Deposu & Gerçek Zamanlı CQRS Projeksiyonları
Etki alanı gerçeklerini yalnızca-eklenebilir akışlar olarak kaydeden, gerçek zamanlı okuma modellerini optimize sorgu depolarına asenkron yansıtan mimari.
Dayanıklı Yürütmeli (Durable Execution) Dağıtık İş Akışı Motoru
Temporal.io ile güçlendirilmiş, çoklu-servis işlemlerinde nihai tutarlılık ve otomatik telafi garantileyen orkestratör tabanlı dağıtık saga motoru.
Veritabanı WAL Okumasıyla Sıfır-Kaymalı Transactional Outbox Hattı
Debezium CDC ve Outbox Event Router kullanarak PostgreSQL WAL mutasyonlarını Kafka konularına aktaran sıfır-dual-write işlemsel entegrasyon hattı.
Çift-Harcama Korumalı Dağıtık Finansal Defter (Ledger)
Deterministik doğal idempotency anahtarları, iki aşamalı rezervasyon onayları ve veritabanı tekil dizin kısıtları kullanan sıfır çift-harcama ödeme mimarisi.
Kendi Kendini İyileştiren DLQ & Otomatik Yeniden Oynatma Hattı
Otomatik şema onarımı, üstel geri çekilmeli yeniden enjeksiyon ve nöbetçi mühendis inceleme arayüzü sunan akıllı ölü-mektup (DLQ) karantina sistemi.
Bizans-Hata Korumalı Dağıtık Kaynak Kilitleyici
Zombi işçilerin depolamayı bozmasını önlemek için artan fencing belirteçleri sağlayan yüksek güvenilirlikli dağıtık karşılıklı dışlama (mutex) mimarisi.
Sanal Düğümlü Dinamik Tutarlı Hash Halkası (Consistent Hashing)
Düğüm ekleme ve çıkarmada tekdüze anahtar dağılımı ve minimum veri taşınması sağlayan sanal düğümlü (vnode) tutarlı hash halkası mimarisi.
Çakışmasız Çok-Bölgeli Aktif-Aktif Veri Deposu (CRDT)
Yerel yazma gecikmesi ve matematiksel olarak garanti edilmiş nihai yakınsama sağlamak için Çakışmasız Çoğaltılmış Veri Tipleri (CRDT) kullanan çok-bölgeli aktif-aktif veritabanı.
Ayarlanabilir Tutarlılıklı Geniş-Sütunlu Veritabanı (Wide-Column)
Dynamo prensipleri, ayarlanabilir okuma/yazma tutarlılık seviyeleri ve arka plan okuma onarımı (read repair) uygulayan geniş-sütunlu dağıtık depolama.
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.