Skip to content
Optimal Lab

System design · interactive

Consensus with Raft

Five servers must agree on the same sequence of writes even when some crash. Raft elects one leader, the leader replicates each write, and a write counts once a majority has it. Step through a leader failure.

  • Aterm 1

    leader

    1. x=1

  • Bterm 1

    follower

    1. x=1

  • Cterm 1

    follower

    1. x=1

  • Dterm 1

    follower

    1. x=1

  • Eterm 1

    follower

    1. x=1

Filled log entries are committed; faded ones are not yet.

  • A → B: ♥
  • A → C: ♥
  • A → D: ♥
  • A → E: ♥

A is leader for term 1. It sends heartbeats so followers know it's alive. Everyone has committed x=1.

step 1 of 10
1

One leader per term

The leader handles all writes and sends heartbeats. Terms number each election, so stale leaders can be recognised.

Followers just follow.

2

Election by majority vote

A follower whose randomised timeout fires starts an election. Each node votes once per term; a majority wins.

Random timeouts avoid split votes.

3

Commit on a majority

The leader appends the write, replicates it, and commits once a majority has stored it. Any future leader must have it too.

5 nodes survive 2 failures.

4

Old leaders step down

A node that sees a higher term becomes a follower and takes the leader's log. A minority partition can never commit anything.

etcd, Consul and CockroachDB use Raft.

In production

Tools and technologies

Consensus sits under most coordination services.

Not tied to one language — use these names when you search docs or design a system.