Build a gossip-based key-value store

This is the exact 8-node graph and the exact runGossip simulator from the gossip chapter — nothing re-implemented, just placed at each node's real ring position. Click "gossip one round" and watch node by node: each one flips from believing key@15 belongs to node 0 (the ring's wraparound owner) to believing it belongs to the newly-joined node 8, exactly when gossip reaches it — never before, never for a reason other than having heard the news.

Nothing here is new math — it's three earlier results, composed:

A node's answer to "who owns this key" is just owner(k) evaluated against that node's own, possibly-stale membership view — and gossip is exactly the mechanism that view catches up through.

• membership view — the set of nodes a given node currently believes are part of the ring; gossip is what keeps it converging toward the truth.
• $I_t$ — which of the 8 original nodes have, by round $t$, heard that node 8 joined.
• concurrent write — two writes to the same key whose vector clocks don't dominate each other, because they landed on nodes with different membership views.

1. A join is just a membership fact spreading by gossip

   "Node 8 exists" is no different from any other rumor: it starts at one node and spreads via the same fanout-bounded gossip rounds as before — there's no separate join protocol to learn.

2. Disagreement during convergence is exactly a concurrent write

   While gossip is still spreading, different nodes have different membership views and so can genuinely disagree about a key's owner — that's precisely the situation vector clocks exist to detect and later reconcile, not a bug in either mechanism.

Push the fanout up and convergence visibly speeds up, exactly as it did in the gossip chapter. Below the graph, node 0 (already informed) and node 6 (still stale) each accept a write to the same key while they disagree about who even owns it — their vector clocks come back concurrent. Click "merge" and watch the two histories combine into one, using the identical mergeClocks function from the Dynamo-style-storage chapter.

The same 8-node gossip graph, fanout 2, starting from node 0 — node 8 joins at ring position 15, and key@15 is the one being tracked:

1. Before anyone hears: owner is node 0

   With only the original 8 nodes in view, assignKey(15, ...) finds no node at or past position 15, so it wraps around to the smallest position — node 0. This is consistent hashing's rule, unchanged.

2. Gossip spreads the join exactly as before

   Fanout 2 from node 0 — the identical trace the gossip chapter already worked through by hand:

   1. Round 1 reaches $\{0,1,4\}$
   2. Round 2 reaches $\{0,1,2,3,4,5,7\}$ — 7 of the 8 nodes
   3. Round 3 finally reaches the last holdout, node 6 — all 8 nodes now agree
3. A concurrent write lands mid-convergence

   At round 2:

   • Node 0 (informed) accepts a write, recording $\{0{:}1\}$
   • Node 6, the one holdout, also accepts a write, recording $\{6{:}1\}$

   Concurrent, because neither node's view agreed on the key's owner yet, let alone on each other's write.

4. Round 3 and a merge resolve everything at once

   Once round 3 finishes, every node's local assignKey call agrees the owner is node 8. And merging the two pending writes gives $\{0{:}1, 6{:}1\}$ — a single reconciled history, with nothing lost from either side.