Consensus Protocol

The guarantee that nothing bad happens during the consensus process. In formal terms, safety ensures that no two nodes in the cluster will ever commit different values for the same log entry or state transition. This property is non-negotiable for financial ledgers and compliance-audited systems.

• Key Mechanism: Nodes must agree on a single, immutable sequence of commands.
• Violation Example: A split-brain scenario where two partitions accept conflicting writes.
• Protocols: Raft enforces safety by requiring a leader to have the most up-to-date log before accepting writes.

The guarantee that something good eventually happens. Liveness ensures the system continues to process new requests and does not deadlock indefinitely. A protocol that prioritizes safety over liveness may halt during a network partition, while one prioritizing liveness risks inconsistency.

• Trade-off: The CAP theorem dictates you cannot have both perfect availability and strong consistency during a partition.
• Mechanism: Leader election timeouts and heartbeat intervals are tuned to detect failures and re-establish a functioning quorum.
• Geo-Impact: Cross-region latency directly impacts the speed of leader election, requiring careful timeout calibration.

The capacity of the consensus group to withstand a defined number of node failures without losing data or availability. In a system of 2f + 1 nodes, the cluster can tolerate up to f simultaneous failures.

• Quorum Math: A 5-node Raft cluster tolerates 2 node failures; a 3-node cluster tolerates only 1.
• Failure Modes: Handles crash faults (nodes stopping) and omission faults (network drops). Byzantine fault tolerance is required for malicious actors.
• Geo-Strategy: Distributing nodes across three availability zones ensures survival of a full zonal outage.

Once a transaction is committed by a quorum, it is permanently recorded and will survive subsequent crashes. This is achieved by writing the log entry to persistent storage on a majority of nodes before acknowledging the client.

• Commit Process: The leader replicates the entry to followers, and only responds to the client after a majority has flushed the data to disk.
• Recovery: After a crash, a node replays its local write-ahead log to reconstruct its state.
• Sovereign Implication: Ensures that a geo-partitioned database does not lose a legally binding transaction even if a regional power failure occurs.

A leader-based consensus protocol designed for understandability. A single elected leader manages log replication to follower nodes. Key mechanisms:

• Leader Election: Uses randomized timers to trigger elections when heartbeats fail
• Log Replication: Leader appends entries, followers acknowledge, commit on majority
• Safety: Ensures committed entries are durable and never overwritten
• Membership Changes: Supports joint consensus for adding/removing nodes

Raft decomposes consensus into independent subproblems, making it easier to implement correctly than Paxos. Used extensively in etcd, Consul, and TiKV.

A family of protocols for achieving consensus in a network of unreliable processors. Core components:

• Proposers: Suggest values to be agreed upon
• Acceptors: Vote on proposed values, forming the quorum
• Learners: Record the final agreed-upon value

Multi-Paxos optimizes the basic protocol by electing a distinguished proposer to reduce message overhead. Cheap Paxos reduces hardware requirements by using auxiliary acceptors. Paxos tolerates crash failures but requires 2F+1 nodes to survive F failures.

A consensus mechanism that tolerates arbitrary node failures, including malicious behavior. Unlike crash fault tolerance, BFT assumes nodes may lie, collude, or send contradictory messages. Practical Byzantine Fault Tolerance (PBFT) requires 3F+1 nodes to survive F Byzantine faults. Key properties:

• Safety: All non-faulty nodes agree on the same value
• Liveness: The system continues making progress
• Accountability: Faulty nodes can be identified

Used in blockchain networks and high-security aerospace systems where adversarial conditions are expected.

A consistency mechanism where read and write operations require acknowledgment from a configurable number of replicas. Tunable parameters:

• Write Quorum (W): Number of replicas that must confirm a write
• Read Quorum (R): Number of replicas consulted for a read
• Replication Factor (N): Total number of replicas

Strong consistency requires W + R > N, ensuring every read sees the latest write. Eventual consistency allows W + R ≤ N for lower latency. This model underpins Dynamo-style databases like Cassandra and Riak.

An atomic commitment protocol ensuring all nodes in a distributed transaction either commit or abort uniformly. Phases:

• Phase 1 (Prepare): Coordinator asks all participants if they can commit
• Phase 2 (Commit/Abort): If all vote 'yes', coordinator sends commit; otherwise abort

Blocking problem: If the coordinator fails after sending prepare but before commit, participants are blocked indefinitely. Three-Phase Commit (3PC) adds a pre-commit phase to reduce blocking risk. Used in XA transactions and distributed SQL databases.

The consensus protocol powering Apache ZooKeeper, designed for primary-backup systems requiring high throughput and low latency. Key characteristics:

• Leader-centric: A single leader broadcasts state updates to followers
• FIFO ordering: Messages are delivered in the order they were proposed
• Crash recovery: Uses epoch numbers to handle leader failures cleanly
• Pipeline support: Allows multiple outstanding proposals for higher throughput

ZAB guarantees that if a leader commits a message, any subsequent leader will also have that message. Critical for Kafka, Hadoop, and HBase coordination.