> KARŞILAŞTIRMA MATRİSİ // SÜRÜM 1.0
22 Dağıtık Teknoloji Karşılaştırma Matrisi
CAP/PACELC Teoremleri, Raft vs Paxos, Azami Verim, p99 Gecikme ve Tam Bir Kez (EOS) Garantileri
| Teknoloji / Platform | Kategori | Uzlaşma Mekanizması | Teslimat Semantiği | Lineerleştirilebilirlik | Maksimum Verimlilik | p99 Gecikme | Tahmini TCO & Lisans |
|---|---|---|---|---|---|---|---|
Apache Kafka (KRaft) Kritik kurumsal olay omurgası, finansal defter hatları ve yüksek hacimli veri akış tüketimi. | STREAMING LOG | KRaft (Kafka Raft Quorum) Leader-Follower (ISR - In-Sync Replicas) | Strict Exactly-Once | Configurable | 1,500,000 msg/sec/broker | 4.2ms | Medium - High (Tiered storage reduces cold retention cost) Apache 2.0 |
Redpanda Milisaniye-altı borsa ve işlem platformları, gerçek zamanlı oyun durumları ve kaynak kısıtlı uç (edge) dağıtımlar. | STREAMING LOG | Raft (per-partition consensus) Raft Quorum Groups | Strict Exactly-Once | Strict | 2,800,000 msg/sec/node | 0.9ms | Low - Medium (3x less hardware due to zero JVM overhead) BSL 1.1 / Community |
Apache Pulsar Çok-kiracılı bulut platformları, küresel coğrafi replikasyon ve milyonlarca bağımsız konu gerektiren sistemler. | STREAMING LOG | Quorum (BookKeeper Ledgers) Decoupled Compute (Broker) + Segmented Storage (Bookies) | Strict Exactly-Once | Configurable | 1,800,000 msg/sec/cluster | 3.5ms | Medium - High (Higher operational component footprint) Apache 2.0 |
RabbitMQ (Quorum Queues) Karmaşık AMQP yönlendirme, ayrıntılı iş dağıtımı, öncelikli kuyruklar ve request-reply RPC hatları. | MESSAGE BROKER | Raft (per-queue state machine) Raft Replicated Queues | At-Least-Once | Strict | 85,000 msg/sec/node | 8.5ms | Low (Minimal operational overhead for standard queuing) Mozilla Public License 2.0 |
NATS JetStream Bulut-yerel mikroservisler, IoT uç cihaz telemetrisi, düşük gecikmeli pub/sub ve merkeziyetsiz servis ağları. | MESSAGE BROKER | Raft (Metadata & Streams) Raft Asset Clustering | Strict Exactly-Once | Strict | 3,200,000 msg/sec/node | 0.6ms | Very Low (Extremely lightweight Go binary, tiny memory footprint) Apache 2.0 |
Temporal.io Karmaşık dağıtık sagalar, insan-onaylı iş akışları, finansal ödeme süreçleri ve uzun süreli dayanıklı işlemler. | WORKFLOW ORCHESTRATION | Delegated to Storage Backend (Cassandra/Postgres/MySQL) Sharded History Service with Optimistic Concurrency | Strict Exactly-Once | Strict | 45,000 workflows/sec | 12.0ms | Medium (Requires dedicated database storage management) MIT (Server) / Apache 2.0 (SDKs) |
Debezium CDC Sıfır-dual-write Transactional Outbox mimarileri, önbellek geçersiz kılma ve veritabanı değişiklik akışı. | STREAMING LOG | Delegated to Database WAL & Kafka Connect Logical Database Replication Slot Streaming | At-Least-Once | Strict | 120,000 changes/sec | 15.0ms | Low (Runs on existing Kafka Connect infrastructure) Apache 2.0 |
etcd Kubernetes küme durumu, dağıtık kilitleme, servis keşfi ve dinamik konfigürasyon koordinasyonu. | KEY VALUE COORDINATION | Raft Single Raft Quorum Group | Strict Exactly-Once | Strict | 40,000 ops/sec | 2.8ms | Low (Standard 3 or 5 node deployment) Apache 2.0 |
Apache Cassandra Yüksek yazma hacimli zaman serisi verileri, IoT telemetri toplama ve çok-bölgeli aktif-aktif depolama. | WIDE COLUMN | Paxos (Lightweight Transactions) & Gossip Ring Masterless Peer-to-Peer (Dynamo Consistent Hashing) | At-Least-Once | Configurable | 450,000 writes/sec/cluster | 5.5ms | Medium (Requires active anti-entropy repair and compaction tuning) Apache 2.0 |
ScyllaDB Ultra-düşük gecikmeli geniş-sütunlu veri deposu, AdTech teklif işleme ve yüksek frekanslı sensör analitiği. | WIDE COLUMN | Raft (Schema/Topology) & Gossip Ring Shard-per-Core Asynchronous C++ Engine | At-Least-Once | Configurable | 1,800,000 writes/sec/cluster | 1.2ms | Low - Medium (Consolidates 3x Cassandra nodes into single host) AGPL 3.0 / Commercial |
Google Cloud Spanner Kıtalar arası katı serializability ve sıfır bakım gerektiren küresel bankacılık ve finans sistemleri. | DISTRIBUTED SQL | Multi-Paxos + TrueClock (Atomic & GPS Hardware) Multi-Region Multi-Paxos Paxos Groups | Strict Exactly-Once | Strict | 600,000 trans/sec | 8.5ms | High (Premium managed enterprise cloud pricing) Proprietary Managed Cloud |
CockroachDB Standart Postgres SQL uyumluluğu gerektiren çok-bulutlu ve hibrit dağıtık ilişkisel uygulamalar. | DISTRIBUTED SQL | Multi-Raft + Hybrid Logical Clocks (HLC) Range Partitioned Multi-Raft Consensus | Strict Exactly-Once | Strict | 220,000 trans/sec | 9.8ms | Medium - High (Enterprise licensing for multi-region features) BSL 1.1 / Enterprise |
TiDB (PingCAP) Büyük ölçekli MySQL sharding dönüşümü, hibrit işlemsel ve analitik iş yükleri (HTAP). | DISTRIBUTED SQL | Multi-Raft (TiKV Storage Engine) Decoupled Stateless Compute + Stateful Multi-Raft Storage | Strict Exactly-Once | Strict | 350,000 trans/sec | 7.4ms | Medium (Open-source core with enterprise cloud option) Apache 2.0 |
Vitess Mevcut MySQL veritabanlarının devasa yatay ölçeklenmesi (YouTube, Slack, GitHub ölçeği). | DISTRIBUTED SQL | MySQL Native Replication + etcd Coordination Horizontal Sharding over Autonomous MySQL Instances | At-Least-Once | Sequential | 1,200,000 queries/sec | 3.1ms | Low - Medium (Leverages standard commodity MySQL servers) Apache 2.0 |
Redis Cluster Dağıtık bellek-içi önbellekleme, hız sınırlayıcı token-bucket yapıları ve oturum yönetimi. | KEY VALUE COORDINATION | Gossip Membership + Asynchronous Primary-Replica 16,384 Hash Slot Sharding with Primary-Replica Failover | At-Most-Once | Eventual | 1,200,000 ops/sec/node | 0.4ms | Low - Medium (In-memory storage footprint) SSPL / Redis Source Available |
Aerospike Gerçek zamanlı dolandırıcılık tespiti, finansal risk profilleme ve aşırı ölçekli gerçek zamanlı teklif sistemleri. | KEY VALUE COORDINATION | Paxos-derived Strong Consistency Mode Hybrid Memory Architecture (Index in RAM, Data on NVMe) | Strict Exactly-Once | Strict | 4,000,000 ops/sec/cluster | 0.5ms | Low (Dramatically cheaper than Redis at terabyte scale via NVMe) Community / Commercial |
YugabyteDB Çok-bölgeli dağıtım ve kesintisiz yükseltme gerektiren doğrudan dağıtık PostgreSQL alternatifi. | DISTRIBUTED SQL | Raft (per-tablet consensus) DocDB Storage Engine with Multi-Raft Tablets | Strict Exactly-Once | Strict | 180,000 trans/sec | 8.2ms | Medium (Open-source core with managed cloud options) Apache 2.0 |
Apache Flink Gerçek zamanlı karmaşık olay işleme (CEP), durum bilgili anomali tespiti ve sürekli akış dönüşümleri. | STREAM PROCESSING | Chandy-Lamport Distributed Snapshot Checkpointing Stateful Stream Operators with RocksDB State Backends | Strict Exactly-Once | Strict | 3,000,000 events/sec | 1.8ms | Medium - High (Requires dedicated streaming cluster infrastructure) Apache 2.0 |
ClickHouse Trilyonlarca olay satırı üzerinde saniye-altı analitik sorgular, gerçek zamanlı gözlemlenebilirlik ve log analitiği. | DISTRIBUTED SQL | ClickHouse Keeper (Raft-compatible) & ReplicatedMergeTree Multi-Primary Asynchronous or Raft Keeper Replication | At-Least-Once | Eventual | 15,000,000 rows/sec/node (Ingest) | 18.0ms (Aggregations) | Very Low (Extreme compression ratios reduce disk cost by 80%) Apache 2.0 |
AWS SQS & SNS Sunucusuz (serverless) mikroservis ayrıştırma, asenkron iş kuyrukları ve AWS ortamında yayılımlı bildirimler. | MESSAGE BROKER | Internal AWS Paxos/Quorum Infrastructure Multi-AZ Redundant Storage | At-Least-Once | Sequential | Virtually Unlimited (Standard) / 3,000 msg/sec (FIFO) | 18.0ms | Pay-per-use (Zero server provisioning, low cost for bursty loads) Proprietary Managed Cloud (AWS) |
Azure Event Hubs Doğrudan Kafka protokol uyumluluğu ve ADLS Gen2 aktarımı ile Azure üzerinde kurumsal akış tüketimi. | STREAMING LOG | Internal Azure Fabric Service & Service Bus Architecture Multi-AZ Partition Replication with Dedicated Tiers | At-Least-Once | Configurable | 2,000,000 msg/sec | 8.0ms | Medium (Billed by Throughput Units or Processing Units) Proprietary Managed Cloud (Microsoft) |
Dapr (Distributed Application Runtime) Standartlaştırılmış pub/sub, durum yönetimi, iş akışları ve sırlar soyutlaması gerektiren çok-dilli mikroservisler. | WORKFLOW ORCHESTRATION | Pluggable (Delegated to Underlying State Store) Sidecar Architecture with Standardized gRPC/HTTP APIs | At-Least-Once | Configurable | 150,000 ops/sec | 2.5ms (Sidecar overhead: ~0.8ms) | Low (Runs as a lightweight container sidecar) Apache 2.0 |
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.
Teknoloji Seçimi & Matris SSS
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.