> CANON #06 // DISTRIBUTED SYSTEMS & EVENT-DRIVEN
Yüksek Verimli Dağıtık Sistemler & Olay-Güdümlü Mimari
CAP & PACELC teoremleri, Raft uzlaşması, log-merkezli akış, Transactional Outbox ve reaktif backpressure standartlarında kesin mühendislik kanonu.
Bölümleme, throughput ve düğüm kapasitesi hesapla
54 olgunluk seviyeli Terraform & Kubernetes planları
CAP, Raft, Kafka, Outbox ve CRDT derinlemesine analiz
Kafka, Redpanda, Temporal, ScyllaDB kıyaslaması
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 Sistemlerin 6 Temel Sütunu
CAP ve PACELC ödünleşimlerini yöneten, veri kayıplarını ve kilitlenmeleri önleyen yapısal sütunlar.
Log-Merkezli Olay Akışı & Bölümleme
Sıfır-kopyalama I/O ve deterministik bölümleme ile olay üreticilerini tüketicilerden ayıran yüksek verimli, yalnızca-eklenebilir (append-only) dağıtık commit logları.
Uzlaşma (Consensus) & Durum Makinesi Replikasyonu
Ağ kopmaları ve düğüm çökmeleri altında lider seçimi, dönem (term) doğrulaması ve lineerleştirilebilir yazma operasyonları sağlayan deterministik uzlaşma protokolleri.
Event Sourcing & Komut-Sorgu Sorumluluk Ayrımı (CQRS)
Durum değişikliklerini değişmez (immutable) etki alanı olayları serisi olarak modellerken yazma mutasyonlarını sorgu-optimize okuma projeksiyonlarından fiziksel olarak ayıran mimari.
İşlemsel Outbox (Transactional Outbox) & Saga Orkestrasyonu
Veritabanı transaction logları (CDC) ve telafi edilebilir iş akışı sagaları aracılığıyla mikroservis sınırları arasında atomik durum mutasyonları ve olay yayımı güvencesi.
Tutarlı Hashleme (Consistent Hashing), Sharding & Multi-Master CRDT’ler
Büyük veri kümelerini tutarlı hash halkaları, ayarlanabilir kopya quorumları ve matematiksel çakışmasız replikasyon (CRDT) ile dinamik küme topolojilerine yatay bölme.
Reaktif Akış Kontrolü, Devre Kesiciler (Circuit Breakers) & Yük Dökme
Dağıtık sistemleri çekme-tabanlı (pull-based) reaktif akış, token-bucket hız sınırları ve spekülatif koruma istekleri ile basamaklı kuyruk tükenmesi ve lag sarmallarından koruma.
24 Gerçek Dünya Arıza Modu & Müdahale Senaryoları
Split-brain, dual-write sapması, zombi liderler ve rebalance fırtınaları için Prometheus kuralları.
Split-Brain Bölünmesi & Iraksak Quorumlar
Ağ bölünmesi çitleme (fencing) yapılmamış kümeyi iki ayrık alt-kümeye ayırır; her iki taraf da çoğunluk quorumuna sahip olduğuna inanarak çelişkili mutasyonları kabul eder.
sum by (cluster) (rate(etcd_server_leader_changes_seen_total[2m])) > 2 or count(raft_is_leader == 1) > 1Dual-Write Mutasyon Kayması & Dağıtık Senkronizasyon Kaybı
Uygulama önce ilişkisel veritabanına yazar, ardından Kafka’ya olay yayınlar. Adımlardan biri çökerse veya başarısız olursa veritabanı durumu olay logundan kalıcı olarak sapar.
abs(sum(rate(db_orders_created_total[5m])) - sum(rate(kafka_topic_orders_messages_in_total[5m]))) > 0.05Sınırsız Tüketici Gecikme (Consumer Lag) Sarmalı & Disk Tükenmesi
Aşağı akış tüketici işleme süreleri uzar, broker üzerinde okunmamış mesajlar birikir. Tüketici gecikmesi (lag) broker diskleri %100 dolana veya log bölütleri silinene dek katlanarak artar.
sum by (topic, group) (kafka_consumergroup_lag) > 50000 and rate(kafka_consumergroup_lag[5m]) > 0Zehirli Mesaj (Poison Pill) & Tüketici Grubu Kilitlenmesi
Bozuk bir yük veya yakalanmayan deserialization hatası tüketicinin çökmesine ve aynı offset noktasında sürekli baştan başlayarak kilitlenmesine neden olur.
sum by (consumer_group) (rate(kafka_consumer_failures_total[2m])) > 10 and delta(kafka_consumer_offset[5m]) == 0Yavaş Kalp Atışlarında Rebalance Fırtınası Sarmalı
Tüketiciler ağır iş yüklerini işlerken `max.poll.interval.ms` süresini aşar. Grup koordinatörü tüketicinin öldüğünü varsayar ve kümeyi sürekli durduran rebalance fırtınası tetikler.
rate(kafka_server_GroupCoordinator_RebalancesTotal[2m]) > 0.5Dağıtık Kilitlenme (Deadlock) & Saga Telafi Açlığı
Koreografi tabanlı bir saga 4. adımda hata alır ancak 2. adımın telafi işlemi ağ kopması yüzünden başarısız olur; harici banka hesapları veya envanter süresiz bloke kalır.
sum(temporal_workflow_failed_total{workflow_type="OrderFulfillmentSaga"}) > 0Sıkça Sorulan Teknik Sorular (FAQ)
Linearizability, Transactional Outbox, Raft ve reaktif akışlar üzerine derin teknik yanıtlar.
Sıkça Sorulan Teknik Sorular (FAQ)
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.
Hibrit Mantıksal Saatler (HLC) ve TrueClock, dağıtık veritabanlarında fiziksel saat kaymasını nasıl çözer?
Fiziksel sistem saatleri NTP gecikmesi, sıcaklık ve donanım kristal kusurları nedeniyle kayar. Last-Write-Wins (LWW) için fiziksel saatlere güvenmek yeni güncellemeleri sessizce yok eder. Google TrueClock bunu her veri merkezinde atomik saatler ve GPS alıcıları kullanarak çözer; saat belirsizliğini dar bir aralığa ($epsilon \approx 1-7ms$) sınırlar ve nedensel sıralamayı garanti etmek için "commit wait" bekletmesi uygular. Hibrit Mantıksal Saatler (HLC) ise fiziksel duvar saatini Lamport mantıksal sayaçlarıyla 64-bitlik bir tam sayıda birleştirir: fiziksel bileşen gerçek zamanı izlerken, mantıksal bileşen aynı milisaniye içinde gerçekleşen nedensel olaylarda artırılır.
Redis SETNX ile uygulanan basit dağıtık kilitlerin yıkıcı arıza modları nelerdir?
Basit dağıtık kilitler (`SET resource_id token NX PX 10000`) gerçek dünyada çöker: 1. Bir istemci kilidi alır ve TTL süresini (örn. 15 sn) aşan beklenmedik bir JVM Garbage Collection duraklaması yaşarsa Redis kilidi otomatik düşürür. 2. İkinci bir istemci kilidi alır. 3. İlk istemci duraklamadan uyanır, kilidin hala kendisinde olduğunu varsayar ve İstemci 2 ile aynı anda paylaşılan depolamaya yazarak veriyi bozar. Martin Kleppmann, zombi yazımları engellemek için dağıtık kilitlerin depolama katmanında doğrulanan kesin artan fencing belirteçleri sağlamak ZORUNDA olduğunu kanıtlamıştır.
İtme-tabanlı olay akışları neden OOM çöküşlerine yol açar ve çekme-tabanlı backpressure bunu nasıl çözer?
İtme-tabanlı (push-based) akışta üreticiler veriyi yazabildikleri en yüksek hızda iletir. Aşağı akış tüketici işleme hızı yavaşlarsa (veritabanı gecikmesi veya harici API nedeniyle), tüketilmeyen mesajlar bellek tamponlarında birikir. Bellek kullanımı sürekli artar ve sonunda Linux OOM killer konteyneri aniden öldürür. Reaktif Akışlar (RSocket, Project Reactor) akış kontrolünü çekme-tabanlı (pull-based) backpressure’a çevirir: abone yalnızca işleyebileceği kapasitedeki mesaj miktarını (`request(n)`) açıkça talep eder. Yukarı akış üreticisi, abone yeni talep iletmedikçe fiziksel olarak daha fazla mesaj gönderemez.
Kafka KRaft, ZooKeeper’ı ortadan kaldırırken bölüm metaveri bütünlüğünü nasıl garanti eder?
Eski Kafka mimarisinde ZooKeeper metaveriyi harici olarak tutuyordu; bu durum çift-kontrolör senkronizasyonuna ve milyonlarca bölüm içeren kümelerde dakikalarca süren failover duraklamalarına yol açıyordu. Kafka Raft (KRaft - KIP-500), metaveri yönetimini doğrudan Kafka içine dahili bir Raft commit logu (`@metadata`) olarak taşır. Özel bir KRaft kontrolör quorumu metaveri logunu bellekte tutar ve diske snapshot alır. Yeni lider metaveri logunu zaten RAM üzerinde replike etmiş olduğundan failover anında gerçekleşir (<500ms); bu sayede Kafka kümeleri on milyonlarca bölüme kadar ölçeklenebilir.
At-Least-Once ile Effectively-Once semantiği arasındaki kesin mimari fark nedir?
At-Least-Once teslimat hiçbir olayın kaybolmamasını garanti eder; ancak ağ yeniden denemeleri ve tüketici yeniden başlatmaları aynı kaydın birden fazla kez teslim edilip işlenmesine yol açabilir. Güvenilmez ağlar üzerinden rastgele koordinesiz dağıtık sınırlar arasında fiziksel "Gerçek Exactly-Once" teslimat matematiksel olarak imkansızdır (İki General Problemi). Sistemlerin pratikte başardığı şey "Effectively-Once" (veya İşlemsel Exactly-Once) semantiğidir: üreticiler idempotent sıra kimlikleri kullanır, broker bir işlem koordinatörü oturumu içinde tekrarları eler ve tüketiciler mükerrer kayıtları atmak için ya idempotent mutasyon işleyicileri ya da benzersiz veritabanı kısıtları kullanır.
Kurumsal mühendislik ekipleri dağıtık kümeler için Kaos Mühendisliği ve Jepsen doğrulamasını nasıl uygulamalıdır?
Kurumsal ekipler sürekli bir hata enjeksiyonu döngüsü benimsemelidir: 1. Hazırlık (staging) ortamlarında asimetrik ağ bölünmeleri, 100ms paket gecikmeleri ve rastgele SIGKILL süreç sonlandırmaları uygulamak için Chaos Mesh veya LitmusChaos konuşlandırın. 2. Kaos altındaki kümeye eşzamanlı okuma ve yazma işlemleri yürüten istemci test koşucuları yazın. 3. Tüm yürütme geçmişlerini (zaman damgaları, iş parçacığı kimlikleri, girdiler ve çıktılar) kaydedin. 4. Ağ bölünmeleri sırasında bayat okuma, kirli yazma veya kayıp güncelleme olmadığını matematiksel olarak kanıtlamak için bu geçmişleri Knossos veya Porcupine gibi Jepsen linearizability denetleyicilerine besleyin.