consensus
Imagine a committee that has to settle on one date for an event, but they can only communicate by passing notes that sometimes get lost, and some members might leave the room partway through. Somehow the whole committee must still end up agreeing on the same single date — not two different dates, not no date. Consensus is exactly this problem for computers: getting a group of separate machines to agree on a single value (the next command to run, who is leader, whether a transaction committed) even though messages can be delayed or lost and some machines can crash.
A good consensus protocol must guarantee a few things together: everyone who decides must decide the same value (agreement); the value decided must be one that was actually proposed (validity); and the system must eventually decide rather than stall forever (termination). The famous protocols that achieve this are Paxos (correct but notoriously hard to understand) and Raft (designed specifically to be understandable, now widely used). They typically work through a leader and majority voting: a proposed value becomes the decision only once a majority (a quorum) of nodes have accepted it. Because any two majorities of the same group must overlap in at least one node, two conflicting decisions cannot both gather a majority — that overlap is the trick that prevents disagreement.
Why it matters, and the honest limits: consensus is the rock that reliable distributed systems are built on — it underlies replicated databases, lock services, and the leader elections that keep clusters coherent. But it is not magic. It costs rounds of messages, so it is slower than a single machine just deciding alone. And there is a deep theoretical result (the FLP impossibility) showing that in a fully asynchronous network where even one node may crash, no protocol can guarantee it will always terminate — real systems sidestep this using timeouts and randomness, accepting that they make progress in practice rather than in the worst theoretical case. Consensus needs a majority to be reachable, which is why it ties directly into the CAP theorem: during a partition that splits the group, the minority side cannot make progress.
Five replicas of a database must agree on the order of writes. Using Raft, the leader proposes "write X = 7 is entry number 12". Only once at least 3 of the 5 (a majority) have stored it does it count as committed. If the leader crashes, a new one is elected and continues — but a partition holding only 2 of the 5 can never reach 3, so it safely refuses to commit rather than risk disagreement.
Agreeing on one value despite lost messages and crashes, by requiring overlapping majorities.
Consensus is not free: it costs message rounds and needs a reachable majority, so a partitioned minority deliberately stops making progress to stay safe. The FLP result means no protocol can guarantee termination in a fully asynchronous network; real ones rely on timeouts.