The network separates K1 and K2 from the rest. Which group writes position 84 And who is leading them?

The group of K3, K4, and K5 has 3 of 5 nodes. K3 becomes the new leader there; K1 and K2 pause.

Without separation, K4 and K5 fail. Can the inventory service still stipulate stock bookings? What if K3 fails?

With K1, K2 and K3 yes, these are 3 from 5. If K3 also fails, stay 2 from 5: The cluster pauses until a node is back.

Instead of five, a team wants to operate only four nodes in order to save costs. What speaks in favour, what speaks against?

For this: one node less operation. Against: The majority is in 3 from 4, so the cluster, as with three nodes, can only cope with one failure. I recommend three or five nodes.

MechanismChapter II · Distribution · Building block 6 of 6

Consensus

Consensus allows multiple participants to set the same binding state or order. A protocol must also deal with failures and delayed messages.

By Michael Meierhoff · Meierhoff Systems

MajorityMore than half of all nodes.
LeaderAssigns values to a log position.
Pause instead of split brainMinority does not accept entries.

Context

Why this is important

If several replicas propose different changes at the same time, the system needs a binding order, otherwise the booths will run apart. The protocol must also cope with failures and delayed messages. Quorum and replication deepen your own building blocks.

This building block deals with agreement on an orderly state. Quorum numbers describe confirmation groups; Saga coordinates business steps across multiple transactions.

At a glance · Leader replicates log to the majority

The leader appends an entry to its log and replicates it; once a majority confirms, the entry is committed.

Shop example · Majority reviews

Majority under failure and partition

Variant: A separately operated inventory service uses multiple replicas to log changes to shared stocks in an orderly manner. The shop itself remains a modular monolith.

This is how you read the picture

Majority The label “Majority: 3 of 5” appears above the nodes.
Leader The dark node; after the partition, K3 becomes the new leader.
Pause instead of split brain The group with K1 and K2 shows “no majority – paused”.

Majority: 3 of 5

5 of 5 · Commits: Log position 84

A majority is reachable: the leader commits the entry once it confirms it.

Five nodes replicate the inventory service log. Turn nodes off or partition the network to see which group can still commit entry 84.

Consensus for a log position

Round 12 begins
Set leader and position
The elected leader handles log position 84 for the inventory service.
Proposal A
Record the first value
The leader assigns “Inventory −1 for SKU-42” to position 84.
At the same time
Handle the competing proposal
“Inventory −2 for SKU-42” competes; the log keeps it out of position 84.
Confirmation
Commit one value
Participants confirm value A for position 84 in round 12.
Apply
Apply the order
Replicas apply the committed entry at the same log position; proposal B remains separate.

Example of a leader-based replica log: the round commits exactly one value to the next position.

Benefits & limitations

Helps if:

Distributed state changes requiring an authoritative order need a shared decision by the nodes.
Majority acknowledgement protects committed log entries against the individual node failures the protocol tolerates.
Loss of a majority marks the point at which new commits must pause.

Boundaries

Without a majority, the cluster accepts no new committed entries; plan this pause as part of operations.
Consensus orders only the replicated log; external effects need their own retry and state handling, such as Idempotency.
Geographically dispersed majorities increase acknowledgement latency; assess node placement against timing targets and Quorum.

In practice

Determine which state requires a binding order and who belongs to the cluster. Use an established protocol implementation instead of your own voting logic.
Check the commit boundary, loss of majority and leader changes against the log. Committed entries must remain in the same order after a permitted change.
Practise membership changes, restart from snapshots and loss of majority. Quorum explains thresholds; Recovery covers resuming operation.

Read the detailed explanation

A consensus protocol lets distributed participants agree on a shared, ordered log state. Raft separates leader election, replication and safety rules. Committed entries remain authoritative across permitted leader changes.

A reachable majority enables progress; without one, the cluster cannot commit a new authoritative decision. Timing assumptions affect availability, while protocol rules aim to prevent conflicting histories. Consensus coordinates the log, but external side effects still need separate handling.

Quorum describes the required response sets; Recovery covers operation after failure. Consensus protocols combine majority rules with an authoritative log order.

Paxos is the older protocol; Raft was described with understandability in mind. A reachable majority enables new authoritative decisions; without it, the cluster pauses. This pause protects a single authoritative log order and prevents conflicting histories. This is why odd node counts such as three or five are used.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
The network separates K1 and K2 from the rest. Which group writes position 84 And who is leading them?
View the solution with justification
The group of K3, K4, and K5 has 3 of 5 nodes. K3 becomes the new leader there; K1 and K2 pause.
ApplyingTransferred to a new situation
Without separation, K4 and K5 fail. Can the inventory service still stipulate stock bookings? What if K3 fails?
View the solution with justification
With K1, K2 and K3 yes, these are 3 from 5. If K3 also fails, stay 2 from 5: The cluster pauses until a node is back.
EvaluateWeighing an alternative
Instead of five, a team wants to operate only four nodes in order to save costs. What speaks in favour, what speaks against?
View the solution with justification
For this: one node less operation. Against: The majority is in 3 from 4, so the cluster, as with three nodes, can only cope with one failure. I recommend three or five nodes.

Explore further

These optional deepenings complement the learning goal of this page.

Leases and fencing tokens

A lease grants an owner the right to control a task for a limited time. After it expires, a new owner can take over; a paused former owner may still resume work later. Issue an increasing fencing token on each takeover, and make the protected store reject every write whose token is lower than the token already accepted for that resource.

A lease alone replaces neither consensus nor checks at the resource access boundary. Fencing prevents a delayed former owner from writing with an older token after a takeover.

For testingLet an inventory worker lose its lease in the shop, then return late with a reservation. Check that the new worker receives a higher fencing token and that, after accepting it, the database rejects the old write attempt even when the former worker becomes reachable again.

References

Continue on the learning path

With that, you have Distributed systems run through. It continues with Runtime & operations.

6 Building blocks

Next areaRuntime & operations