Consensus (Raft)

How N nodes agree on an ordered sequence of operations despite failures and network delays, without getting stuck.

Problem

Several nodes maintain the same replicated state machine (key-value store, business log, leader-election table). They must agree on the exact order of writes to avoid divergence, and survive minority failures. Paxos has solved this since 1989 (Lamport) but is famously hard to grasp. Raft was designed to be implemented correctly by ordinary teams.

Forces

• FLP impossibility — no perfect consensus under asynchrony; a timeout is required.
• The more nodes in the quorum, the stronger the safety but the higher the write latency.
• A network failure can isolate the leader; we must detect and re-elect quickly.
• The algorithm must be implementable by humans without brain cramps (Paxos was problematic).

Solution

Raft splits consensus into three sub-problems: (1) leader election — one leader per term, elected by majority when the previous one stops sending heartbeats; (2) log replication — the leader receives all writes, has them validated by a majority (quorum N/2+1) before committing; (3) safety — a committed log cannot be lost; a new leader must have the most up-to-date log in the quorum. The separation makes the algorithm didactic and each module testable independently.

Structure

           ┌───────── Term 7 ─────────┐
Client ───► Leader (Node A) ───► Followers (B, C, D, E)
              │                       │
              │ AppendEntries(log[i])  │
              │ ◄─────── ack ──────────┤
              │                       │
              │ when majority ack      │
              │   ──► commit index = i │
              │                       │
              ▼
        State machine apply(log[i])

If leader A goes silent:
  Followers wait election_timeout (150-300ms randomised)
  First to time out becomes candidate, requests votes
  Wins if majority votes ──► becomes leader for term 8

EDI implementation

You don't write Raft yourself for an EDI hub; you consume Raft. Typical case: etcd Raft for the Kubernetes registry hosting the hub. Or CockroachDB (Raft per range) as the multi-region transactional database of a global EDI hub — each order survives the loss of a datacenter. For EDI architects, understanding Raft enables correct quorum sizing and election-timeout calibration based on inter-DC latency.

Anti-patterns

• Quorum of 2 nodes — any failure suspends writes (always 3, 5 or 7).
• Election timeout too short vs RTT — election never converges.
• Bandwidth saturated by replication — heartbeats stop arriving, useless elections triggered.
• Configuration change (membership) without the joint consensus protocol — split brain guaranteed.
• Believing Raft provides end-to-end exactly-once — must combine with application-level idempotency.

Related patterns

• Leader Election — Raft sub-problem surfaced separately.
• Partition Tolerance (CAP) — Raft picks CP on partition.
• Event Sourcing — Raft log is itself an event journal.
• Guaranteed Delivery — guarantee built on top of Raft.

Sources

• Ongaro D., Ousterhout J. — In Search of an Understandable Consensus Algorithm, USENIX ATC 2014. raft.github.io/raft.pdf
• etcd documentation — Raft implementation. etcd.io/docs/v3.5/learning/why
• Kleppmann M. — Designing Data-Intensive Applications, O'Reilly 2017, ch. 9.