> ARCHITECTURE CATALOG // V1.0
18 Distributed Systems Reference Architectures
54 Maturity Configurations, CAP/PACELC Trade-Offs, Zero-Loss Delivery & Production Terraform Manifests
Ultra-High-Throughput KRaft Event Mesh
ZooKeeper-less enterprise event streaming mesh powered by Kafka Raft (KRaft) metadata quorum, tiered remote cloud storage, and partition-level idempotency.
Hardware-Optimized Thread-per-Core C++ Streaming
Zero-JVM, thread-per-core C++ event streaming platform utilizing Linux io_uring and Seastar architecture for deterministic sub-millisecond p99 latencies.
Multi-Tenant Segmented Storage Streaming
Decoupled compute-and-storage streaming architecture utilizing Apache Pulsar brokers and Apache BookKeeper ledgers for infinite retention and millions of topics.
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.
Distributed Systems Architecture 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.