Consensus Algorithms - Raft & Paxos

Day 006: Consensus Algorithms - Raft & Paxos

Discovering how real systems achieve the "impossible" - agreement in the face of failures

Today's "Aha!" Moment

The insight: Reaching agreement is mathematically impossible in truly asynchronous systems (FLP theorem)—yet real systems achieve consensus billions of times per second. The trick? Relax the assumptions.

Why this matters: This is computer science at its most beautiful and practical. The FLP impossibility theorem (1985) proved that consensus is impossible with even one faulty process in an asynchronous system. Yet etcd, Consul, and ZooKeeper achieve consensus constantly, powering Kubernetes, HashiCorp's infrastructure, and distributed databases worldwide. Understanding how theory meets practice here reveals a fundamental pattern in systems engineering: theoretical impossibility doesn't mean practical impossibility—it means understanding which assumptions to relax.

This realization transforms how you approach "impossible" problems. When you hit a theoretical wall, you don't give up; you ask: "Which assumptions can I pragmatically relax?" In consensus, the answer is: add timeouts (partial synchrony), accept probabilistic guarantees (not absolute), and require majority (not unanimity). Suddenly, the impossible becomes not just possible but production-ready at massive scale.

The universal pattern: Theoretical impossibility + relaxed assumptions = practical solutions

How to recognize when this applies:

Common misconceptions before the Aha!:

Real-world examples across domains:

  1. Technology - Kubernetes: Every kubectl command involves etcd achieving Raft consensus. When you deploy a pod, multiple master nodes must agree on the cluster state. FLP says impossible, etcd says "done" in milliseconds by using timeouts and majority voting. Handles billions of operations daily across millions of clusters.

  2. Nature - Ant Colonies: Ants achieve consensus on nest sites through quorum sensing—no central coordinator, majority signals dominance. If some ants "fail" (get lost), the majority still decides. Nature solved distributed consensus 100 million years before computer scientists formalized it.

  3. Social Systems - Jury Decisions: Legal systems require majority (or unanimous) verdicts with time bounds. If deliberations stall indefinitely (pure async), judge can declare mistrial (timeout). Real consensus requires bounded time assumptions, just like Raft.

  4. Everyday Life - Group Restaurant Decisions: "If no one responds in 5 minutes, we're going to pizza" is literally Raft's timeout mechanism! The impossibility of unanimous agreement becomes practical with deadlines and majority voting.

  5. Industry - CockroachDB: Google's distributed SQL database uses Raft for every range of data. When you write to the database, multiple replicas must agree on the order of operations. Handles millions of consensus decisions per second, achieving 99.99% availability by accepting that perfect consistency is impossible but practical consistency is achievable.

What changes after this realization:

Meta-insight: The most impactful computer science often comes from pragmatically rejecting impossibility theorems. FLP says "impossible with these constraints," engineers say "let's change the constraints." Same pattern repeats: Halting Problem (undecidable in general, but solvable for specific programs we care about), Byzantine Generals (impossible with 1/3+ traitors, but we can tolerate up to that threshold with clever protocols), Two Generals Problem (impossible to guarantee delivery, but TCP makes it work 99.99% of the time with retries and timeouts).

The lesson isn't that theory is wrong—it's that theory illuminates boundaries. Engineering finds creative ways to work within relaxed boundaries. Understanding both theory (what's impossible) and practice (what's achievable anyway) is the hallmark of deep systems thinking. Consensus algorithms are the perfect exemplar: theoretically impossible, practically ubiquitous, and philosophically profound.

Why This Matters

Consensus algorithms are the invisible backbone of modern distributed systems. Every time you use Kubernetes, deploy on AWS, interact with a blockchain, or query a distributed database, consensus algorithms are working behind the scenes to ensure consistency and reliability.

The problem: How do multiple independent computers agree on a value when any of them can fail, networks can partition, and messages can be delayed or lost?

Before consensus algorithms:

After consensus algorithms (Raft/Paxos):

Real-world impact:

Kubernetes/etcd: Every Kubernetes cluster uses etcd (Raft-based) to store cluster state. With over 5.6 million Kubernetes clusters worldwide (2024), etcd handles billions of consensus operations daily. When a master node fails, Raft ensures automatic failover in seconds, achieving 99.95%+ uptime for critical infrastructure.

HashiCorp Consul: Service discovery and configuration using Raft. Deployed across tens of thousands of companies, handling millions of service health checks per second. Netflix uses Consul to coordinate microservices across multiple regions.

CockroachDB: Distributed SQL database using Raft per data range. Achieves "impossible" combination of SQL semantics with horizontal scalability. Powers financial systems requiring both consistency and availability (within CAP theorem limits).

Blockchain: While Bitcoin uses Nakamoto consensus (different but related), Ethereum 2.0 uses Casper FFG (Paxos-inspired). These consensus mechanisms secure hundreds of billions of dollars in value.

What you'll gain:

Learning Objectives

By the end of this session, you will be able to:

  1. Explain the FLP impossibility theorem - Understand why consensus is theoretically impossible in pure asynchronous systems, and identify the specific assumptions that make it impossible

  2. Describe how Raft achieves consensus - Explain the core mechanisms: leader election, log replication, and how timeouts enable practical consensus despite FLP

  3. Implement basic Raft leader election - Build a simplified simulation showing how follower → candidate → leader transitions work with majority voting

  4. Compare crash failures vs Byzantine failures - Distinguish between different failure models and understand why Byzantine fault tolerance is harder (and when it's needed)

  5. Analyze consensus vs gossip protocols - Explain when eventual consistency (gossip) suffices versus when strong consistency (consensus) is necessary, with concrete examples

  6. Connect to CAP theorem - Relate consensus algorithms to the CAP theorem trade-offs and understand why consensus chooses consistency + partition tolerance over availability during partitions

Core Concepts Explained

This section provides self-contained explanations of consensus fundamentals

Concept 1: The Consensus Problem

What it is: Consensus is the problem of getting multiple distributed nodes to agree on a single value or sequence of values, even when some nodes may fail.

Why it matters: Without consensus, distributed systems can't maintain consistency. Imagine a banking system where different replicas disagree on account balances, or Kubernetes where master nodes have different views of which pods are running. Consensus prevents these catastrophic scenarios.

How it works:

  1. Proposal: One or more nodes propose values
  2. Agreement protocol: Nodes communicate to reach agreement following specific rules
  3. Decision: Once sufficient nodes agree (typically majority), the value is decided
  4. Termination: The protocol must eventually terminate with a decision

Mental model: Think of consensus like a committee making a decision. Everyone can propose ideas, they discuss and vote, and once a majority agrees, the decision is final. Unlike a simple vote, consensus protocols must handle network delays, message loss, and members who fail mid-decision.

Key characteristics:

When to use it:

Common pitfalls:

Concept 2: The FLP Impossibility Theorem

What it is: The Fischer-Lynch-Paterson (FLP) theorem (1985) proves that in a fully asynchronous distributed system, it's impossible to guarantee consensus if even one process can fail, even by crashing (not malicious).

Why it matters: This is one of the most important impossibility results in distributed systems. It tells us the theoretical boundaries—what cannot be achieved under certain assumptions. More importantly, it shows us which assumptions we must relax to make consensus practical.

The assumptions FLP makes:

  1. Purely asynchronous: No bounds on message delays or processing time (messages can take arbitrarily long)
  2. Deterministic algorithm: The consensus algorithm must be deterministic
  3. At least one process can fail by crashing (not malicious)
  4. Eventual message delivery: Messages eventually arrive (no permanent loss)

Why consensus is impossible under these assumptions: In a purely asynchronous system, you can't distinguish between a crashed node and a very slow node. If you wait indefinitely for a slow node, you violate termination. If you give up on it, you might exclude a non-faulty node, violating correctness. There's no deterministic way to resolve this ambiguity.

Mental model: Imagine trying to get a group decision via email, but some people might have died (crashed). You can't set any time limit because email delivery has no upper bound (purely async). If someone hasn't responded, are they dead or just slow? You can never know for certain, so you can never safely terminate the decision process. This is FLP in everyday terms.

How real systems "violate" FLP:

  1. Add timeouts (partial synchrony): Assume messages usually arrive within reasonable time. If timeout expires, assume node failed. This relaxes "purely asynchronous" to "mostly synchronous."
  2. Use randomization: Randomized consensus algorithms (like Ben-Or) work with probability 1, not guaranteed termination. This relaxes determinism.
  3. Add failure detectors: Oracles that (imperfectly) detect failures. Relaxes pure asynchrony with additional hardware/network assumptions.

Practical implications:

Why this isn't just theoretical: Understanding FLP explains why:

Concept 3: Raft Consensus Algorithm

What it is: Raft is a consensus algorithm designed for understandability (unlike Paxos). It achieves consensus by electing a leader, having the leader replicate logs to followers, and committing entries once a majority acknowledges them.

Why it matters: Raft is used in production by etcd (Kubernetes), Consul (HashiCorp), CockroachDB, and many other systems. It's the most widely deployed modern consensus algorithm. Understanding Raft means understanding how critical infrastructure actually works.

How it works:

1. Leader Election:

2. Log Replication:

3. Safety Properties:

Mental model: Think of Raft like a classroom. The teacher (leader) gives instructions (log entries) to students (followers). If the teacher leaves (fails), students hold an election for a new teacher (leader election). The new teacher must have attended all previous classes (complete log) to be elected. Once a majority of students have written down an instruction (majority acknowledgment), it's permanent (committed). If the classroom splits into two groups (partition), only the majority group can continue with a teacher; the minority must wait.

Key characteristics:

Simple example of leader election:

class RaftNode:
    def __init__(self, node_id, peers):
        self.node_id = node_id
        self.peers = peers
        self.state = "follower"  # follower, candidate, or leader
        self.current_term = 0
        self.voted_for = None
        self.votes_received = 0
        self.election_timeout = random.uniform(150, 300)  # milliseconds

    def start_election(self):
        """Transition to candidate and start election"""
        self.state = "candidate"
        self.current_term += 1
        self.voted_for = self.node_id
        self.votes_received = 1  # vote for self

        print(f"Node {self.node_id}: Starting election for term {self.current_term}")

        # Request votes from peers
        for peer in self.peers:
            peer.request_vote(self.current_term, self.node_id)

    def request_vote(self, term, candidate_id):
        """Handle vote request from candidate"""
        # If candidate's term is higher and we haven't voted, grant vote
        if term > self.current_term and self.voted_for is None:
            self.current_term = term
            self.voted_for = candidate_id
            return True
        return False

    def receive_vote(self, granted):
        """Count votes and become leader if majority achieved"""
        if granted:
            self.votes_received += 1

        # Majority is (n/2) + 1
        majority = (len(self.peers) + 1) // 2 + 1

        if self.votes_received >= majority:
            self.state = "leader"
            print(f"Node {self.node_id}: Became leader for term {self.current_term}")

# Example usage (3-node cluster):
node1 = RaftNode(1, [])
node2 = RaftNode(2, [])
node3 = RaftNode(3, [])

node1.peers = [node2, node3]
node2.peers = [node1, node3]
node3.peers = [node1, node2]

# Simulate: node1's timeout expires first
node1.start_election()
# Node 1: Starting election for term 1
# Receives votes from node2 and node3 (majority of 3)
# Node 1: Became leader for term 1

Why this example works: This demonstrates the core of Raft leader election: (1) timeout triggers election, (2) candidate increments term and votes for itself, (3) requests votes from peers, (4) peers grant votes if term is higher, (5) candidate becomes leader upon receiving majority. In production, this would include heartbeats, log comparison, and network RPC, but the essence is here.

When to use Raft:

Common pitfalls:

Concept 4: Crash Failures vs Byzantine Failures

What it is:

Why it matters: The failure model determines algorithm complexity and minimum number of nodes needed:

Why Byzantine tolerance is harder:

When to use each:

Real-world examples:

  1. etcd (Raft): Crash failures only. Assumption: all nodes in Kubernetes cluster are trusted. Cheaper, faster, simpler.
  2. Bitcoin/Ethereum: Byzantine tolerance required. Anyone can join the network (untrusted). Nakamoto consensus and Proof-of-Work provide Byzantine fault tolerance.
  3. Google Spanner: Crash failures with trusted hardware (TrueTime API assumes GPS/atomic clocks don't lie). If you control the hardware, crash tolerance is sufficient.

Common pitfalls:

Concept 5: Consensus vs Gossip - When to Use Each

What it is:

Consensus characteristics:

Gossip characteristics:

When to use consensus (Raft/Paxos):

When to use gossip:

Real-world hybrid approach - HashiCorp Consul:

Comparison table:

Consensus (Raft/Paxos) Gossip (Epidemic)
Consistency Strong (immediate) Eventual (seconds-minutes)
Latency O(round trips) ~3-10ms O(log N) rounds, <1ms per hop
Scalability 3-7 nodes typical 100s-1000s nodes
Partition tolerance Blocks minority Continues in all partitions
Use case Leader election, config Membership, metrics

Common pitfalls:

Guided Practice

Hands-on activities to solidify understanding through doing

Activity 1: Raft Leader Election Simulation

Goal: Build a basic 3-node Raft cluster simulation to see leader election in action

Instructions:

  1. Setup nodes (5 min): Create 3 RaftNode instances with random timeouts
import random

class RaftNode:
    def __init__(self, node_id):
        self.node_id = node_id
        self.state = "follower"
        self.current_term = 0
        self.voted_for = None
        self.election_timeout = random.uniform(150, 300)
  1. Implement election logic (10 min): Add methods for starting election and voting
def start_election(self):
    self.state = "candidate"
    self.current_term += 1
    self.voted_for = self.node_id
    # Request votes from peers

def handle_vote_request(self, term, candidate_id):
    if term > self.current_term:
        self.voted_for = candidate_id
        return True
    return False
  1. Test election (5 min): Simulate timeout triggering election
# Node 1 timeout expires → becomes candidate → requests votes
# Nodes 2 and 3 grant votes (term is higher)
# Node 1 receives 3/3 votes (including self) → becomes leader
  1. Handle split vote (5 min): Simulate scenario where 2 nodes timeout simultaneously
# Both become candidates, split the vote (1 vote each, plus self)
# Neither achieves majority → timeout and retry with new term

Validation:

Expected outcome: Working simulation showing:

If it doesn't work:

Activity 2: Compare Crash vs Byzantine Failures

Goal: Understand the difference between failure models through simulation

Setup:

Instructions:

  1. Crash failure simulation (10 min):
# 3 nodes voting on a value
# Node 1 proposes value=42
# Node 2 votes yes, Node 3 crashes (no response)
# Result: 2/3 majority → consensus achieved on 42
  1. Byzantine failure simulation (10 min):
# 3 nodes voting on a value
# Node 1 proposes value=42
# Node 3 (Byzantine) sends value=42 to Node 1, value=99 to Node 2
# Node 1 sees: [42, 42] → thinks consensus on 42
# Node 2 sees: [42, 99] → no majority, confusion
# Result: Cannot achieve consensus! (Need 4 nodes for 1 Byzantine)
  1. Expand to 4 nodes (5 min):
# 4 nodes, 1 Byzantine
# Byzantine sends conflicting messages
# 3 honest nodes see majority of their own messages → consensus possible
# This shows why 3f+1 is needed for f Byzantine failures

Analysis questions:

Expected outcome: Clear intuition for why Byzantine failures are harder (3f+1 vs 2f+1)

Activity 3: CAP Theorem Connection (Optional)

Goal: Understand how consensus relates to CAP theorem trade-offs

Instructions:

  1. Network partition scenario:

  2. 5-node Raft cluster

  3. Network partition: {Node1, Node2} vs {Node3, Node4, Node5}

  4. Client tries to write to Node1

  5. Analyze behavior:

  6. Node1 cannot reach majority (has 2/5, needs 3/5)

  7. Node1 blocks the write (unavailable during partition)
  8. Node3 side has majority (3/5) and can elect leader and accept writes

  9. This is Raft choosing Consistency + Partition tolerance over Availability

  10. Compare to gossip:

  11. Same partition with gossip protocol

  12. Both sides continue accepting writes
  13. Eventual consistency after partition heals
  14. This is gossip choosing Availability + Partition tolerance over Consistency

Reflection: When is it acceptable to block (Raft) vs when must you stay available (gossip)?

Session Plan (60 minutes total)

Preparation (15 min)

Core Work (35-40 min)

Wrap-up (5-10 min)

Buffer

Timing notes:

Deliverables & Success Criteria

Required Deliverables

Optional (Stretch Goals)

Success Rubric

Minimum (Foundation achieved):

Target (Solid mastery):

Excellent (Deep understanding):

Troubleshooting

Issue: "I don't understand why FLP says consensus is impossible when etcd clearly does it"

Why it's confusing: FLP has specific assumptions that aren't obvious at first

Clarification: FLP assumes purely asynchronous systems (no time bounds on messages). Real networks are partially synchronous (messages usually arrive quickly, with occasional delays). Raft uses timeouts (e.g., 150-300ms) to detect failures, which requires partial synchrony. FLP says "impossible without time bounds," Raft says "we have time bounds in practice." The theorem is correct; we just don't operate under its assumptions.

Mental model: FLP is like saying "you can't navigate without any sense of time." True! But in reality, we have clocks/timeouts, so we can navigate. The impossibility tells us what's necessary (time bounds), not that the problem is unsolvable in practice.

Issue: "My leader election keeps having split votes and never terminates"

Why it happens: If all nodes use the same timeout duration, they timeout simultaneously and repeatedly split the vote

Fix: Use randomized timeouts (150-300ms random range). This breaks symmetry so nodes timeout at different times, dramatically reducing probability of split votes. After a split vote, each node should randomize again for retry.

Prevention: Always use random timeouts for leader election, never fixed intervals. This is a core Raft design element.

Issue: "Why do we need 3f+1 nodes for Byzantine failures? Isn't majority (2f+1) enough?"

Diagnosis: This is the most common confusion about Byzantine fault tolerance

Explanation: With crash failures, non-faulty nodes always tell the truth, so majority voting works. With Byzantine failures, faulty nodes can send different messages to different nodes.

Example: 3 nodes (A, B, C), C is Byzantine:

With 4 nodes (A, B, C, D), C is Byzantine:

When to worry: If implementing blockchain or cross-org systems (need Byzantine tolerance). For internal systems with trusted nodes, 2f+1 with crash-only Raft is sufficient.

Issue: "Consensus seems slow (multiple round trips). Why not just use gossip everywhere?"

Why consensus is slower: Consensus requires multiple round trips for safety:

  1. Leader proposes value
  2. Followers acknowledge
  3. Leader commits and notifies followers Minimum 2 round trips, often 3 for full commit notification.

When consensus is necessary:

When gossip suffices:

Fix: Use hybrid approach like Consul: Raft for critical consistency (config, leader election), gossip for scalable info (membership, health checks). Don't use consensus for everything; it doesn't scale beyond ~7 nodes effectively.

Issue: "How does Raft handle network partitions? Does it violate CAP theorem?"

Diagnosis: Misunderstanding CAP theorem and what Raft guarantees

Clarification: Raft does not violate CAP theorem. During network partition:

Raft chooses CP (Consistency + Partition tolerance), sacrificing A (Availability in minority partition). This is a valid CAP choice, same as Google Spanner.

When to worry: If your system requires availability during partitions, Raft isn't suitable. Use eventually consistent systems (Cassandra, DynamoDB) that choose AP. Most systems prefer consistency over availability, making Raft a good choice.

Advanced Connections

Deep patterns and cross-domain insights

Connection 1: Raft's Majority Quorums ↔ Database Quorum Writes

The parallel: Raft's requirement for majority acknowledgment before committing is structurally identical to quorum-based replication in distributed databases like Cassandra or DynamoDB.

Real-world case: DynamoDB's Consistency Levels

How it manifests: When you write to DynamoDB with ConsistencyLevel=QUORUM, it waits for W=⌈N/2⌉+1 replicas to acknowledge, exactly like Raft waiting for majority before commit. The math is identical: need majority to ensure overlap with any future majority (intersection property).

Key differences:

When the connection helps: If you understand Raft quorums, you immediately understand why R+W>N is necessary for consistency in Dynamo-style systems. The quorum intersection math is universal across consensus, databases, and distributed storage.

Further exploration: Why does Raft only need R=1 (read from leader) while Cassandra needs R≥2 for strong consistency?

Connection 2: FLP Theorem ↔ Halting Problem

The parallel: Both are fundamental impossibility results showing limits of computation. FLP says "can't decide consensus in pure async," Halting Problem says "can't decide if programs halt in general."

Real-world case: Static Analysis Tools

Key differences:

When the connection helps: Impossibility theorems tell you boundaries, not that problems are unsolvable in practice. Just as linters solve "undecidable" problems for practical code, consensus algorithms solve "impossible" consensus for practical systems. The key is identifying which assumptions you can relax.

Further exploration: What other impossibility theorems (Two Generals, Byzantine Generals) are "violated" in practice through assumption relaxation?

Connection 3: What Changes at Scale (Single Node → Raft Cluster → Multi-Raft Sharding)

Small scale (single node):

Medium scale (3-7 node Raft cluster):

Large scale (multi-Raft sharding - CockroachDB, TiKV):

The invariants (what stays the same):

Why this matters: Single consensus algorithm (Raft) doesn't scale to 1000s of nodes. Large systems use composition (many small Raft groups) not monolithic consensus. Understanding this pattern reveals how real distributed databases work: consensus for replication within shard, sharding for horizontal scale.

Real example: CockroachDB has ~100k Raft groups in large deployments, each group 3-5 nodes, giving both strong consistency (Raft) and horizontal scalability (sharding).

Connection 4: Raft Term Numbers ↔ Lamport Logical Clocks

The parallel: Both use logical counters to order events in distributed systems without relying on physical time.

Real-world case: Vector Clocks in Riak/Cassandra

How it manifests:

Key differences:

When the connection helps: If you understand why Raft needs term numbers (detect stale leaders), you understand why distributed systems need logical clocks (detect stale data). Both solve the problem of ordering without physical time synchronization.

Further exploration: Why do some systems (Google Spanner) use physical clocks (TrueTime) instead of logical clocks? What does that enable?

Resources

Core Resources (Use today)

These are essential for the lesson. Times/sections specified to keep focused.

Optional Depth (If time permits / evening reading)

Original Sources (Historical context)

Key Insights

  1. Theoretical impossibility doesn't mean practical impossibility - FLP proves consensus is impossible in pure asynchrony, yet Raft/Paxos achieve consensus billions of times daily by relaxing assumptions (timeouts, partial synchrony). The lesson: impossibility theorems define boundaries; engineering finds pragmatic paths within relaxed constraints.

  2. Majority quorums ensure safety through intersection - Requiring ⌊N/2⌋ + 1 acknowledgments guarantees any two quorums overlap by at least one node. This simple math ensures the latest committed value is always visible to future operations, preventing split-brain and data loss.

  3. Leader-based designs trade flexibility for simplicity - Raft's strong leader (all operations through leader) creates a single point of coordination but makes the algorithm easier to understand and implement correctly than leaderless alternatives. The cost: leader can become bottleneck; the benefit: simpler reasoning about consistency.

  4. Byzantine tolerance is expensive (3f+1 vs 2f+1) - Tolerating malicious failures requires 3f+1 nodes compared to 2f+1 for crash failures because Byzantine nodes can send conflicting messages. Most systems don't need Byzantine tolerance; crash-only tolerance (Raft/Paxos) is sufficient for trusted environments with huge performance advantage.

  5. Consensus doesn't scale; partition and hierarchy do - Single Raft group limited to 3-7 nodes due to coordination overhead. Large systems (CockroachDB, Spanner) use multiple consensus groups (sharding) or hierarchical consensus. The algorithm doesn't change; the architecture does.

  6. Timeouts are first-class design elements, not afterthoughts - Random election timeouts (150-300ms) are core to Raft's correctness and liveness. They break symmetry in elections, detect failures, and enable practical consensus. Tuning timeouts requires understanding network characteristics and balancing fast failover vs spurious elections.

Reflection Questions

  1. Conceptual understanding: Why does FLP theorem allow Raft to work in practice? What specific assumption does Raft make that FLP doesn't?

  2. Application: You're building a distributed configuration management system (like Consul). When would you use Raft consensus vs gossip protocols for different parts of the system?

  3. Comparison: Explain why 3 nodes can tolerate 1 crash failure but cannot tolerate 1 Byzantine failure. What changes when you add a 4th node?

  4. Connection: How are Raft's term numbers similar to Lamport logical clocks? How are they different? Why does Raft need terms?

  5. Limitation: Raft requires a majority to make progress. What happens during a network partition where you have 2 nodes on one side and 3 on another in a 5-node cluster? Which side can process writes? Why?

  6. Meta/philosophical: The FLP theorem proves something is impossible, yet engineers built systems that do it anyway. What does this tell you about the relationship between theory and practice in computer science? Are impossibility theorems useless, or do they serve a different purpose?

Quick Reference

Key Terms

Key Formulas

Raft States

Follower → (timeout) → Candidate → (majority votes) → Leader
    ↑                       ↓ (loses/splits)
    └──────────────────────┘

Typical Election Timeout

← Back to Learning