Concepts
Replicated log / state machine replication
Intuition
Think of a shared ledger that several bookkeepers each keep their own copy of. To make sure everyone's copy stays identical, only one bookkeeper is allowed to write new entries at a time, and they dictate each new line to the others in the exact same order. As long as everyone copies down the same lines in the same order, anyone can independently total up the ledger and get the same answer — they never need to compare notes on every single line to trust the result.
How it works
In Raft, the leader is the only server that appends new commands to its own log, then sends AppendEntries RPCs in parallel to replicate each entry to its followers in order. An entry becomes "committed" once the leader confirms it has been replicated to a majority of servers in the cluster — at that point it's safe to apply it to the state machine, and every earlier entry in the log is committed too. Consistency across replicas rests on the Log Matching Property: if two logs contain an entry with the same index and the same term, their logs are identical in every entry up to that index. Raft enforces this because every AppendEntries call includes the index and term of the immediately preceding entry, and a follower rejects the RPC if that doesn't match its own log; when a mismatch is found, the leader forces the follower's log to converge to its own by overwriting the conflicting entries. There's a subtlety in the commit rule that protects correctness across leader changes: a leader cannot mark an entry from a previous term as committed just by counting replicas of it — it can only do so after an entry from its own current term has first been replicated to a majority. Together with the election restriction (candidates with stale logs can't win, so any elected leader already holds every previously committed entry — the Leader Completeness Property), this delivers State Machine Safety: no two servers ever apply different commands at the same log index.
In practice
This is the core replication mechanism behind systems like etcd, Consul, and CockroachDB, which use a Raft-replicated log to keep configuration data, service discovery state, or transaction metadata consistent across every node. You'd reach for a replicated log like this whenever multiple servers need to agree, in order, on a single sequence of state-changing operations and keep working correctly even if the current leader crashes mid-stream.
Use it in a design
Practice the cases that rely on this concept in the System Design school.