The previous lesson ended with a single decider whose absence left healthy participants unable to act. Consensus is the answer to that specific problem, and understanding it as the answer to that problem rather than as an abstract algorithm is what makes the rest of it tractable.

What the problem is, restated

A decision that only one machine holds becomes unavailable when that machine does, so any arrangement resting on a single decider inherits that machine's availability.

Restating the problem is the right opening because it connects to the previous lesson. The weakness being addressed is specific.

Why replicating the decider is harder than replicating data

Copies of data can lag harmlessly, while copies of a decision that disagree are worse than no copies at all, since each one can be acted upon.

Drawing the distinction immediately is important because replication was covered already. Deciders cannot be allowed to diverge.

What agreement has to mean here

That the group behaves as one decider would: every member eventually holds the same decisions in the same order, and no member ever holds a decision the group did not make.

Defining the goal precisely is necessary. The property is about a group imitating a single component.

Why an ordered sequence is the right thing to agree on

Any state can be described as the result of applying a sequence of changes in order, so agreeing on the sequence is sufficient to agree on everything downstream.

Introducing the log as the primitive is the central move of the lesson. One abstraction covers all uses.

Why that reduction is so powerful

It means consensus has to solve exactly one problem, agreeing on an ordered list of entries, after which any state machine fed that list arrives at the same place.

Explaining the power of the reduction is worthwhile. The generality is what makes the mechanism reusable.

What a majority buys

Any two majorities of the same group share at least one member, so a decision accepted by a majority cannot be contradicted by another decision also accepted by a majority.

Giving the intersection property is the key insight. The arithmetic does the work.

Why that single property is doing most of the work

Every safety guarantee in these protocols traces back to overlapping majorities, which is why so much of the design is about counting rather than about messages.

Emphasising this is valuable because the protocols look complicated. One fact underpins them.

Why group sizes are odd

An even group tolerates the same number of failures as the odd group one smaller while needing more machines, so even sizes cost without buying.

Covering the practical consequence is right. The convention has a reason.

How many failures a group tolerates

A group of three survives one loss, five survives two, and seven survives three, because a majority must remain reachable.

Giving the numbers is practical. The trade is explicit.

Why larger groups are not simply better

Every entry must reach a majority, so a larger group means more machines to wait for, and the latency rises while the failure tolerance improves.

Explaining the trade is necessary. Size is a decision rather than a maximisation.

Why the group must agree on who is in it

Majorities are defined relative to membership, so a group that disagrees about its own members can form two majorities that do not overlap.

Marking this is essential because membership changes cause real incidents. The definition is itself state.

What safety means in this context

That the group never produces contradictory decisions, which these protocols guarantee unconditionally, regardless of timing, message loss or reordering.

Defining safety is necessary. The guarantee is absolute.

What liveness means in this context

That the group eventually makes progress, which cannot be guaranteed unconditionally, because a sufficiently adversarial network can prevent any group from deciding.

Defining liveness is equally necessary. The second guarantee is conditional.

Why that asymmetry is the right one

A group that stops is unavailable and recoverable, while a group that contradicts itself has corrupted its own history, so correctness is never traded for progress.

Explaining the choice is valuable. The priority is deliberate.

Why no protocol can promise both

Progress requires distinguishing a failed member from a slow one, and on a network where messages can be delayed arbitrarily that distinction cannot be made reliably.

Giving the fundamental limit is worthwhile. The impossibility is informational rather than practical.

Why that limit is tolerable in practice

Real networks are mostly well behaved, so protocols that are always safe and usually live behave well, and the rare stall is an outage rather than a corruption.

Keeping perspective is right. The theoretical limit rarely bites.

What a storage engine gains from all this

A durable, ordered, highly available record of decisions, which is precisely the thing a single engine's log provides locally and nothing provided across machines.

Connecting back to storage is the right turn. The gain is a familiar primitive made available.

Why that is more than just a replicated log

The group can answer questions about the log, accept new entries while members are down, and replace a failed member, none of which a copied file can do.

Distinguishing this from replication is important. The group is active rather than a mirror.

Why this subsumes the previous lesson's problem

A decision held by a group remains available when any member fails, so a participant waiting for an outcome can always get one.

Making the connection explicit is valuable. The blocking window closes.

Why it does not make distributed commit free

The decision is now available and still expensive, since reaching a majority costs a round trip and a durable write on several machines.

Being honest about the remaining cost is necessary. Availability is bought rather than given.

Why the cost is a floor rather than a risk

The latency is predictable and paid every time, where the previous arrangement was cheaper on average and occasionally unavailable for hours.

Framing the trade is the practical core. Predictable expense beats rare catastrophe.

Why it is usually adopted rather than built

The protocols are correct in their rare paths rather than their common ones, so a mature implementation is worth far more than a fresh one.

Giving the practical advice early is right. The build decision is almost always settled.

Why this shape now appears everywhere

Configuration stores, metadata services, lock services, queue brokers and distributed databases all use it, because they all need one available decider.

Noting the ubiquity is useful. The pattern is not confined to databases.

Why knowing the mechanism matters even when it is bought

Its failure modes are specific and recognisable, and systems built on it fail in its terms rather than in their own.

Justifying the lesson is worthwhile. The abstraction leaks in predictable ways.

What to take from the requirement

Three things. Replicating a decider is harder than replicating data because diverging copies of a decision can each be acted upon, so the goal is a group that behaves exactly as one decider would. Agreeing on an ordered sequence of entries is sufficient for everything downstream, because any state is the result of applying changes in order, which is why consensus has only one problem to solve. And the entire safety guarantee rests on overlapping majorities, which also explains why group sizes are odd, why larger groups cost latency, and why the group must agree on its own membership.