Distributed Systems Visualizations
Distributed systems run into three different questions as soon as one machine is no longer enough. Where should each key live? Can several resources apply one transaction together? Can several replicas preserve one log through failures? Consistent hashing, two-phase commit, and Raft answer those questions. Their diagrams may all contain nodes and messages, but their guarantees are not interchangeable.
A cache ring needs placement that stays mostly stable when capacity changes. A bank transfer needs A, B, and its audit log to change together or not at all. A replicated control plane needs one committed history even when messages arrive late or the network splits. Start by naming the job; then choose the mechanism.
Compare the lessons
| Lesson | Main question | Deciding rule | Failure boundary |
|---|---|---|---|
| Consistent Hashing | Which physical node owns a key when membership changes? | first active token clockwise from the fixed key token | only one adjacent interval should change owner; balance is improved, not guaranteed |
| Two-Phase Commit | When may A, B, and the log all change? | every participant votes YES, then all receive the same decision | one NO aborts everyone; a crashed coordinator can leave prepared locks held |
| Raft Consensus | When may a log entry become committed history? | a majority elects the leader and stores its current-term entry | a minority may store an entry but cannot commit it |
The most common category error is to borrow a rule from the wrong row. Raft's three-of-five majority cannot make a three-resource transaction atomic. Two-phase commit's unanimity would make two delayed replicas freeze a five-server log. Consistent hashing decides placement; it does not replicate data or settle conflicting writes.
A Recommended Order
Start with Consistent Hashing on Node joins. Follow K11 across token zero, then watch N4@220 claim (140, 220]. K5, K6, and K7 change owner; nine keys do not. Switch to Node leaves to see one departed interval transfer to its clockwise successor. Finish on Virtual nodes and compare the fixed-key loads 3/2/7 -> 4/5/3.
Continue with Two-Phase Commit on All yes → commit. Pause at two YES votes, at the coordinator's COMMIT decision, and at the blocking window where P1 is still PREPARED and A is still 100. Load One no → abort to watch a YES voter roll back, then Coordinator crash to leave the locks visibly held.
Finish with Raft Consensus on Election + commit. Three votes make a leader; three stored copies make a current-term entry committable. Then run Minority partition. The two-server side can store set y=7 and still stall at 2 / 5, while the three-server side elects a higher-term leader and commits a different entry at the same index.
That order moves from placement, to atomic coordination, to replicated agreement. It also makes the vocabulary harder to blur: an owner is not a participant, a prepared value is not a committed log entry, and a hash-ring token is not a quorum vote.
What to Watch
- In consistent hashing, key dots never move when membership changes. Only their clockwise successor may change.
- A virtual node is another token position for the same physical machine, not another machine.
- In 2PC, a purple proposed value is locked but not applied. Two YES votes never cross
need ALL YES. - In Raft, two stored copies never cross
majority = 3. Storage and commitment are separate beats. - A coordinator crash can block prepared 2PC participants. A Raft partition blocks only the side without a majority.
- None of the three lessons supplies the guarantees of the other two. Real systems often combine them—for example, a hash ring for placement and Raft inside each shard for replication.
Pick a lesson below and keep your eye on its deciding evidence: the clockwise successor, the unanimous vote, or the overlapping majority.