Raft Consensus Algorithm

Raft's core safety property is State Machine Safety: if a server has applied a log entry at a given index, no other server will ever apply a different entry for the same index. This is enforced by:

• Election Restriction: A candidate must contain all committed entries to win an election.
• Log Matching Property: If two logs contain an entry with the same index and term, they are identical in all preceding entries.
• These rules prevent data loss and ensure linearizable semantics for clients.

Raft includes a mechanism for safely changing the set of servers in the cluster (e.g., adding or removing a node) without compromising availability. It uses a joint consensus approach for transition.

• Configuration changes are treated as special entries in the replicated log.
• The cluster transitions through an intermediate configuration (Cold,new) where both old and new majorities are required for agreement.
• This two-phase approach prevents split-brain scenarios that could occur if servers switched configurations simultaneously.

A primary design goal of Raft was to be more understandable than predecessors like Paxos. It achieves this through decomposition into relatively independent sub-problems:

1. Leader election
2. Log replication
3. Safety
4. Membership changes

• This modular structure makes the algorithm easier to teach, reason about, and implement correctly in production systems.

Raft is designed to tolerate non-Byzantine faults, primarily server crashes and network partitions. It maintains availability as long as a majority of servers are operational and can communicate.

• Crashed servers can rejoin the cluster and have their logs updated via the leader's AppendEntries mechanism.
• The protocol includes persistent state (current term, votedFor, log) that must be stored on stable storage before responding to RPCs to survive crashes.
• This focus on crash-recovery faults aligns with common data center failure models, making it practical for real-world deployments.

Conflict-Free Replicated Data Types (CRDTs) are data structures designed for distributed systems that guarantee eventual consistency. They can be updated concurrently without coordination, automatically resolving any conflicts mathematically.

• State-based vs. Operation-based: CRDTs come in two main flavors. State-based CRDTs (CvRDTs) merge entire states, while operation-based CRDTs (CmRDTs) apply commutative operations.
• Alternative Approach: Unlike consensus algorithms like Raft, which use coordination (e.g., a leader) to sequence operations, CRDTs embrace coordination-free execution, making them ideal for collaborative applications and scenarios where network partitions are common.

Vector clocks are a mechanism for tracking causality and the partial ordering of events in a distributed system. Each node maintains a vector of counters, one for every node in the system.

• How it Works: When a node experiences an event, it increments its own counter in the vector. Vectors are attached to messages, allowing recipients to update their view of the system's event history.
• Relation to Consensus: While not a consensus protocol itself, vector clocks are crucial for understanding eventual consistency models. They help detect concurrent updates (which may require conflict resolution) and are foundational for systems that need causal consistency, providing a more precise alternative to Lamport clocks.

The CAP theorem is a fundamental principle in distributed systems stating that it is impossible for a distributed data store to simultaneously provide more than two out of three guarantees: Consistency, Availability, and Partition tolerance.

• Consistency (C): Every read receives the most recent write or an error (linearizability).
• Availability (A): Every request receives a non-error response, without guarantee it contains the most recent write.
• Partition Tolerance (P): The system continues operating despite network partitions.
• Raft's Position: Raft is a CP system. It prioritizes strong consistency and partition tolerance. During a network partition, the leader-eligible majority partition remains available and consistent, while the minority partition becomes unavailable to prevent inconsistent writes.

Eventual consistency is a consistency model for distributed systems where, in the absence of new updates, all replicas will eventually converge to the same state. Temporary inconsistencies are allowed during propagation.

• Mechanism: Updates are propagated asynchronously. Systems often use mechanisms like gossip protocols or CRDTs to achieve this.
• Contrast with Raft: Raft provides strong consistency (linearizability), ensuring any read sees the latest committed write. Eventual consistency offers higher availability and lower latency during partitions but at the cost of temporary staleness or conflicts, which must be resolved. It's a common model for globally replicated databases like DNS or some NoSQL stores.