Dynamo Quorum Tuning Lab (Interactive)
Tune N, R, and W replicas and see overlap, hinted handoff, and node-failure math live. Recreate the Dynamo paper behind Amazon's retail order path: choose replication and quorum factors, kill replicas, and measure consistency overlap, write acceptance via hinted handoff, and key relocation cost.
Dynamo Quorum Tuner (N, R, W)
Configure Amazon's 2007 masterless key-value store: tune replication and quorums, kill replicas, and watch the R + W > N guarantee and latency respond.
How It Works Under the Hood
DynamoDB descends from Amazon's Dynamo paper, born when the retail platform could no longer tolerate a relational single point of failure around checkout. Data is replicated across N nodes on a consistent-hash ring, and quorums R+W>N guarantee read-write overlap that, combined with vector clocks and read repair, delivers eventual consistency with single-digit millisecond availability. When nodes are down, writes succeed as long as W is reachable somewhere, with hints carrying mutations until the replica returns.
Core Architectural Principles
- Quorum overlap: R+W>N forces reads and writes to share at least one replica, so acknowledgments converge through read repair.
- Hinted handoff: coordinator stores mutations for downed replicas, keeping writes available while durability temporarily drops.
- Ring rebalancing: adding one node to the hash ring relocates only 1/(N+1) of keys instead of reshuffling everything.
When asked about DynamoDB or Cassandra consistency, speak in quorum parameters: "With N=3, R=2, W=2 the read and write sets always intersect." Then explain what happens when replicas are down — hinted handoff trades durability for availability, making the system AP under CAP. Interviewers listen for that explicit tradeoff, not vague "it eventually syncs."
Tuning quorums trades read freshness and write latency against survival of replica outages; strong consistency costs both round trips and availability.