> COMPARISON MATRIX // V1.0
22 Distributed Technology Comparison Matrix
CAP/PACELC Trade-Offs, Raft vs Paxos, Peak Ingress, p99 Latency & Exactly-Once Semantics
| Technology / Platform | Category | Consensus Model | Delivery Semantics | Linearizability | Max Throughput | p99 Latency | TCO & License |
|---|---|---|---|---|---|---|---|
Apache Kafka (KRaft) Mission-critical enterprise event backbone, financial ledger pipelines, and high-volume stream ingestion. | 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 Sub-millisecond latency trading platforms, real-time gaming state, and resource-constrained edge deployments. | 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 Multi-tenant cloud platforms requiring geo-replication, millions of topics, and instant partition rebalancing. | 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) Complex AMQP routing, granular worker job distribution, priority queuing, and request-reply RPC. | 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 Cloud-native microservices, IoT edge device telemetry, low-latency pub/sub, and decentralized mesh. | 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 Complex distributed sagas, human-in-the-loop workflows, financial payment checkout, and long-running processes. | 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 Zero-dual-write Transactional Outbox architectures, cache invalidation, and real-time database change replication. | 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 cluster state, distributed locking, service discovery, and dynamic configuration coordination. | 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 High-write time-series workloads, IoT telemetry aggregation, and multi-region active-active storage. | 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-low-latency wide-column datastore, AdTech bid evaluation, and high-frequency sensor processing. | 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 Global financial core banking systems requiring strict multi-continent serializability and zero maintenance. | 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 Multi-cloud and hybrid-cloud distributed relational applications requiring standard Postgres SQL compatibility. | 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) Large-scale MySQL sharding replacement, hybrid transactional/analytical processing (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 Massive horizontal scaling of existing MySQL databases (YouTube, Slack, GitHub scale). | 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 Distributed in-memory caching, rate limiting token buckets, session management, and ephemeral queues. | 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 Real-time fraud detection, financial risk profiling, and high-frequency bidding at extreme scale. | 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 Drop-in distributed PostgreSQL replacement requiring multi-region deployment and zero-downtime upgrades. | 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 Real-time complex event processing (CEP), stateful anomaly detection, and continuous stream transformations. | 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 Sub-second analytical queries over trillions of event rows, real-time observability telemetry, and log analytics. | 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 Serverless microservice decoupling, async worker task queues, and fan-out notifications in AWS environments. | 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 Enterprise streaming ingestion on Azure with native Kafka protocol compatibility and direct Capture to ADLS Gen2. | 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) Polyglot microservices needing standardized pub/sub, state management, workflow orchestration, and secrets abstraction. | 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 |
High-Throughput Distributed Systems & Event-Driven Architecture Canon per CAP, PACELC, Raft, and Reactive Streams: Eliminate dual-write drift with Transactional Outbox, block zombie leaders with fencing tokens, and prevent OOM collapses with pull backpressure.
Technology Selection & Matrix FAQs
What is the fundamental mathematical difference between Linearizability and Serializability?
Serializability is a multi-operation, multi-object transactional property: it guarantees that a group of transactions executing concurrently appears to have executed in some valid sequential serial order, but says nothing about real-time wall-clock ordering. Linearizability (atomic consistency) is a single-operation, single-object real-time guarantee: once an operation completes in real physical time, all subsequent operations globally must observe that new value or a newer one. A system providing both guarantees simultaneously is termed "Strict Serializable" or "External Consistent" (e.g. Google Cloud Spanner).
How does the Transactional Outbox pattern mathematically eliminate dual-write mutation drift?
The naive dual-write anti-pattern attempts to execute an RDBMS mutation and publish to Kafka sequentially in application code. If either operation fails, times out, or the process crashes mid-flight, state diverges permanently. The Transactional Outbox pattern stores the outbound event inside a dedicated `outbox_events` table within the EXACT SAME local database transaction as the business entity. Atomicity is guaranteed by local RDBMS ACID properties. A separate Change Data Capture (CDC) engine (such as Debezium) tails the database Write-Ahead Log (WAL) and streams the events to Kafka with guaranteed at-least-once ordered delivery.
When should an architecture select Apache Kafka over RabbitMQ or NATS JetStream?
Select Apache Kafka when you need a persistent, append-only replayable commit log, high aggregate partition throughput (>100k msg/sec), long-term retention (days/weeks/infinite via tiered storage), consumer group replayability, and strict total ordering per partition key. Select RabbitMQ when you need complex AMQP dynamic routing topologies, granular worker queue competition, selective message acknowledgment, and priority queuing. Select NATS JetStream when you need ultra-low-latency (<1ms), lightweight operational footprints (single binary), zero JVM overhead, and decentralized edge or IoT pub/sub.
How does Raft achieve consensus and strictly prevent split-brain during network partitions?
Raft guarantees safety through quorum majorities ($Q = \lfloor N/2 \rfloor + 1$). In an odd-numbered cluster (e.g. 5 nodes), any two majorities of 3 nodes MUST overlap in at least one node. If a network partition splits the cluster into 3 nodes and 2 nodes, only the 3-node partition can gather a majority to elect a leader and commit log entries. The 2-node sub-cluster cannot achieve a quorum ($2 < 3$) and rejects all client writes. Furthermore, monotonic term numbers ensure that any stale leader from a lower term is immediately stepped down when contacting a node with a higher term.
Why does Saga Orchestration scale more reliably than Saga Choreography in production?
In Saga Choreography, microservices listen to domain events and autonomously decide to publish follow-up events or execute compensations. As workflows expand past 4 services, choreography creates invisible cyclic event loops, tangled distributed state, impossible forensic observability, and compensation starvation when edge services fail. Saga Orchestration (using Temporal.io or Cadence) centralizes workflow coordination into a durable state machine: the orchestrator explicitly commands participants, tracks timeouts, executes compensating transactions deterministically on failure, and persists execution history across node crashes.
How do Conflict-Free Replicated Data Types (CRDTs) achieve multi-master convergence without locks?
CRDTs rely on abstract algebra: mutations are structured as join-semilattices equipped with a merge operator ($\sqcup$) that satisfies three mathematical properties: Commutativity ($A \sqcup B = B \sqcup A$), Associativity ($(A \sqcup B) \sqcup C = A \sqcup (B \sqcup C)$), and Idempotence ($A \sqcup A = A$). Because the order and frequency of applying state updates do not change the final merged result, multi-region replicas can accept write mutations locally with zero coordination latency, exchange updates asynchronously, and guarantee mathematical convergence to the exact same state once all updates are observed.