Transactions, Consistency, and Consensus in Distributed Systems

This article introduces the concepts of transactions, consistency, and consensus in distributed systems, explaining how they work together and why they are essential when designing reliable distributed architectures.

1. Review of previous article – It recaps the three common replication models (primary‑slave, multi‑primary, leaderless) and the challenges of partial failures and unreliable clocks.

2. Article overview – The focus is on three guarantees—transactions, consistency, and consensus—detailing their roles, internal relationships, and practical implications, with a look at Kafka as a concrete example.

3. Transactions & external consistency – The ACID properties are explained in depth: atomicity (safe retry without side effects), consistency (invariant enforcement), isolation (various isolation levels, dirty reads, phantom reads, etc.), and durability (persistence guarantees). The section also discusses transaction classification (single‑object vs. multi‑object), safe commit‑retry strategies, and the trade‑offs of different isolation levels.

4. Internal consistency & consensus – Replication lag problems are illustrated with examples (write‑after‑read, monotonic reads, prefix reads). Internal consistency is defined and linked to memory consistency models (linearizability, sequential consistency, causal consistency). Strong consistency (linearizability) is described with client‑read/write scenarios, operation definitions (write, read, CAS), and the need for a total order. Implementation techniques such as Lamport timestamps, total‑order broadcast, and two‑phase commit (2PC) are covered, followed by a discussion of consensus algorithm properties (agreement, honesty, validity, termination) and their relationship to total‑order broadcast.

5. Re‑examining distributed systems – The article outlines ideal goals (single‑view data, serialized operations) and explains why achieving both linearizability and serializability is costly, leading to a spectrum of consistency models.

6. Kafka deep dive – Configuration parameters (replication factor, min.insync.replicas, acks) are examined, showing how they affect consistency guarantees. The newer Kafka transaction support (2PC‑based) is described, including the role of the TransactionCoordinator and the isolation level (read‑committed).

7. Distributed‑system verification frameworks – Two major tools are presented: TLA+ for white‑box formal modeling and Jepsen for black‑box fault‑injection testing. The article briefly explains their architectures and how they were used to validate Kafka’s consistency under failures.

8. Conclusion – The author summarizes the journey through replication, transactions, consistency, and consensus, emphasizing the importance of choosing the right guarantees and using verification tools to ensure correctness in real‑world distributed systems.