Consensus, Raft and Gossip

Consensus, Raft and Gossip

Consensus establishes a replicated decision under explicit majority assumptions; gossip disseminates membership and state but is not consensus. Raft elects a leader for a term, replicates log entries and commits after a majority has stored them under protocol rules. Terms and log matching protect safety across leader changes. Paxos uses proposal and acceptance quorums. Gossip spreads membership or updates; heartbeat timeouts produce suspicion, not proof of death.

Mechanism and worked example

A three-node Raft group can commit when two nodes are available. If only one remains, it cannot safely commit new majority-backed entries. Gossip may temporarily mark a slow but alive node suspect; clients must not equate suspicion with exclusive ownership.

Failure modes and operations

A network partition can isolate a former leader; destination fencing or consensus-backed authority must reject stale writes. Clock pauses and packet delay cause false suspicion. Majority loss stops progress. Unsafe membership changes can threaten quorum safety.

Trade-offs and design boundary

Consensus provides strong coordination but costs network round trips and requires a quorum. Gossip scales dissemination and tolerates temporary disagreement but cannot safely grant exclusive write ownership. Leases reduce coordination only with explicit clock and fencing assumptions.

Interview transfer exercise

For a distributed scheduler, assign ownership through a consensus/lease authority and enforce increasing fencing tokens at the database. Gossip may distribute health but must not act as the lock authority.

Read the diagram

Gossip spreads reachability suspicion → Consensus quorum elects leader → Leader issues increasing epoch → Storage rejects stale epoch writes

View full sizeOpen original

Consensus, Raft and Gossip

Reset viewClose

Mechanism and decision flow for Consensus, Raft and Gossip.