1. Consensus algorithms

Picture a five-node metadata store, etcd-style, that holds the shard-to-primary map for a sharded orders database, the table that tells every service which database server is the primary for each shard. Its nodes are spread across three availability zones.

Now the store's own leader dies in the middle of a failover. Two surviving nodes each decide they are in charge, and each starts handing out a different answer. Half your order writes go to db-b, the other half to db-c. A consensus algorithm is what stops that: it lets a fixed group of nodes agree on one ordered history of changes even when some of them crash or the network drops messages, as long as a majority can still talk.

This comes up whenever your design has a box labelled "leader" or "coordinator": a primary database, a job scheduler, a Kafka controller, a shard map. The interviewer points at it and asks what happens when it dies, and how you avoid two of them. At mid-level, knowing that the store needs a majority and refuses writes without one is usually enough. Senior candidates are expected to walk the protocol itself: how a leader is elected, when a write counts as committed, and what the cluster refuses during a partition. It rarely fills a whole round, but it is the standard deep dive behind every leader box.

This tutorial teaches Raft, with Multi-Paxos mapped onto the same vocabulary, at the depth those follow-ups reach. By the end you can take a five-node cluster and a failure, such as a leader crash or a network split, and say who can become leader, which writes are safe, and what each side of the split refuses to do.