Partitioning and replication
Where keys live and how copies stay in step: consistent hashing with virtual nodes, rendezvous, jump hash and Maglev with animated key movement; an animated Dynamo-style store with preference lists, N/R/W quorums, sloppy quorums and hinted handoff, read repair, vector-clock siblings and Merkle-tree anti-entropy; and the latency and staleness of partial quorums.
Added
Works with
- System design interviews Interview prepsharding, hot keys and replicas in interview architectures, a Dynamo-style key-value store among them, with consistent hashing to run
- Distributed patterns on Redis Databases and streamingRedis Cluster's fixed 16,384 hash slots and live resharding with MOVED and ASK
- MongoDB replica sets and sharding, simulated Databases and streamingMongoDB's own range and hashed sharding, balancer and query targeting
- Offline-first sync and replication Distributed systemsoffline-first multi-master replication, where concurrent writes become CouchDB revision-tree conflicts much like Dynamo siblings
- Consistency models lab Distributed systemsthe five Cosmos DB consistency levels on a replicated store, and a checker for whether a history is linearizable
How to use it
Three tabs about spreading data over machines. Placement compares the ways of deciding which node owns a key and shows which keys move when a node joins or leaves. Dynamo replication is an animated, step-by-step key–value store in the style of Amazon’s Dynamo (DeCandia et al., SOSP 2007) — the design behind Cassandra and Riak. Latency and staleness computes how often a partial quorum returns stale data and what bigger quorums cost in latency. Everything runs in the page.
How to use it
Placement. Pick an algorithm and the number of nodes, virtual nodes and keys. + Add a node and
− Remove change the node set: keys that change owner flash and change colour, and the counters
show how many moved against the minimum possible (1/n of the keys) and against hash mod n. The
ring view draws every token and every key at its hash position; the other algorithms draw the keys
as a grid in key order. Load per node shows the balance; Balance against virtual nodes plots the
coefficient of variation of each node’s share of the ring against the number of tokens per node,
measured and against 1/√v. With Maglev and up to six nodes the 13-slot table is drawn with each
backend’s permutation.
Dynamo replication is a simulator. Pick a scenario and press Start: each step does something
— a put, a get, a crash, a partition, an anti-entropy exchange — plays until it has happened and
pauses so you can read what happened and why, with links to the paper. Next step, Back (the
simulator is deterministic, so it replays), Restart, Play / Pause, Step ⇥ (the next single
event) and ⏭ (the end of the step); space plays and pauses, → is the next step. Speed scales
time (1× is a quarter of a simulated second per real second) and Hop time is how long a message
takes to cross the diagram — the simulated clock slows while one is on its way, without changing
what happens. ⛶ Full screen (or f) gives the diagram the whole window; Escape leaves.
-
The diagram. The ring in the middle: the dots are the nodes' tokens at their true hash positions, each arc coloured by the node that owns it; the black dot is the focused key (
cart:aliceunless you pick another), with its preference list printed in the centre and its replicas outlined in the node’s colour. Around it, one card per node: its keys, the hinted writes it holds for others, and the focused key’s versions with their vector clocks (two side by side are siblings). Two clients at the top. Messages are labelled:put k=v,put k (hint N3),ack,read k, the versions a replica returns,repair k,handoff, Merkleroot hash/level 2exchanges andsync. Tap a node to crash or restart it, isolate it, send a request through it or run anti-entropy with a neighbour; tap a client to put or get. -
Do something. Put and get as either client on any of six keys; set R and W; switch between sloppy and strict quorums; crash, restart, isolate, heal; drop the next write to a node; compare Merkle trees between any two nodes.
-
Replicas of each key: every key’s preference list and every node’s versions (green when the replicas agree). Merkle trees: both trees of the last anti-entropy exchange, with the hashes that differ in red and the ones never compared dashed. Requests: each request, its coordinator, the result and the latency.
-
Settings: nodes, tokens per node, N, R, W, latency, jitter, sloppy quorum, read repair, seed.
Latency and staleness. Set N, R, W, a latency distribution and the mean of each leg of the WARS model. The page shows the probability that a read sent t ms after a write commits returns it, for every R, and a table of every (R, W) with the probability of a fresh read at t = 0 and 10 ms and the p50 and p99 write and read latencies.
What it models
-
Consistent hashing (Karger et al. 1997): nodes and keys hashed onto a 32-bit circle (FNV-1a with the murmur3 finaliser); a key belongs to the first token clockwise; each node may have v tokens (virtual nodes). A node’s share is then a sum of v random arcs, so its coefficient of variation is about 1/√v.
-
Rendezvous hashing (Thaler & Ravishankar 1998): each node scores (node, key) with a hash and the highest score wins.
-
Jump consistent hash (Lamping & Veach 2014): the paper’s function exactly, with its 64-bit linear congruential generator (BigInt in the page), checked against published test vectors. Buckets are numbered, so only the last can be removed.
-
Maglev (Eisenbud et al., NSDI 2016): permutations from offset = h₁ mod M and skip = h₂ mod (M − 1) + 1, and the table filled by Pseudocode 1 (M = 65537 for the statistics, 13 for the drawing) — checked against the paper’s Table 1.
-
Dynamo (§4): the preference list is the next N distinct nodes clockwise (skipping further tokens of a chosen node). A client sends to the first healthy node of the key’s list, which coordinates: for a put it builds a new vector clock from the client’s context and its own counter, writes locally and sends to the others, answering after W acknowledgements; for a get it asks the N replicas, answers after R, and returns every version it cannot order (syntactic reconciliation — siblings are the client’s to merge). With a sloppy quorum, unreachable replicas are replaced by the next healthy nodes, which store the write with a hint and hand it off when the owner is reachable again (§4.6). Read repair: once every replica asked has answered, stale ones get the newest versions. Anti-entropy (§4.7): two replicas build Merkle trees (Merkle 1987) over the keys they share — leaves hash the (key, version) pairs in one slice of the hash space — compare them top down, and exchange only the keys under differing leaves. A read is flagged stale when none of its versions is the newest acknowledged write or concurrent with it.
-
Partial quorums (Bailis et al., Probabilistically Bounded Staleness, VLDB 2012): the WARS model by seeded Monte Carlo — per replica a write delay W, an acknowledgement A, a read request R and a response S, drawn from the chosen distribution with the given means; a write commits at the W-th fastest W + A; a read takes the R fastest R + S and is consistent if one came from a replica the write reached first.
Limits
-
Nodes join and leave only in the Placement tab; the Dynamo ring is fixed for a run (Dynamo’s partition-transfer on membership change is not simulated), and tokens are random (not Dynamo’s later equal-size partitions, §6.2).
-
Vector clocks are never truncated (§4.4 truncates them past 10 entries); there is no gossip-based membership or failure detection — a node is down or up, and the coordinator knows it instantly.
-
Anti-entropy compares the keys two nodes share in one tree (Dynamo keeps one tree per key range); trees are rebuilt for each exchange.
-
The latency explorer assumes independent, identically distributed legs per replica and a coordinator that sends to all N replicas — the model and assumptions of the PBS paper, not measurements of a real system.
Linking to an example
Links can be written by hand. Add a tab after #: placement (the default), dynamo or quorums.
A link’s settings replace this page’s saved settings (a button restores yours); a scenario brings its
own settings, and parameters given with it override them.
| Parameter | Meaning | Example |
|---|---|---|
|
A Dynamo scenario (list below; add |
|
|
The same, without clearing your settings |
|
|
Open the scenario at this step |
|
|
Dynamo nodes, 2–10 |
|
|
Dynamo tokens per node, 1–8 |
|
|
Replicas per key |
|
|
Read quorum |
|
|
Write quorum |
|
|
Sloppy quorum with hinted handoff ( |
|
|
Read repair ( |
|
|
One-way latency, ms |
|
|
Extra random latency up to this, ms |
|
|
Placement algorithm: |
|
|
Placement: nodes, 2–20 |
|
|
Placement: virtual nodes per node (ring), 1–512 |
|
|
Placement: keys, 100–5000 |
|
|
Staleness: |
|
|
Staleness: N |
|
|
Staleness: R |
|
|
Staleness: W |
|
|
Random seed |
|
|
Playback speed: |
|
|
Hop time in seconds ( |
|
Dynamo scenarios:
example= |
Shows |
|---|---|
|
The ring, preference lists and N/R/W quorums (open) |
|
R + W ≤ N: a stale read, and the quorum that prevents it (open) |
|
A replica down: a stand-in takes the write with a hint and hands it off later (open) |
|
A replica missed a write; a read returns the newest and repairs it (open) |
|
A partition, concurrent writes, vector-clock siblings and a client merge (open) |
|
Merkle trees compared top down; only differing ranges exchanged (open) |
|
Six nodes and two clients, no script (open) |
Feedback is a gift. Something to improve, a feature to add, or a bug? Tell me.
Runs entirely in your browser; nothing you type leaves this page.