Design a Distributed Key-Value Store (Dynamo)

Data, Storage & ConsistencyHarddesign-key-value-store

Design a Distributed Key-Value Store (Dynamo)

Design an always-writable key-value store that survives node and datacenter loss, resolves concurrent writes, and repairs its own divergence in the background.

Quorum Reads/WritesVector ClocksMerkle TreesHinted HandoffGossip

Traffic & Capacity Estimates:

100 TB · 1M ops/second · 3 replicas per key · 99.99% write availability

Functional Requirements

•Get and put values by key, replicated to N nodes across failure domains.
•Stay writable during node failure and network partition, reconciling later.
•Detect and repair replica divergence without a full data scan.
•Grow and shrink the cluster online with incremental data movement.

Non-Functional Requirements

•p99 under 10ms for single-key operations.
•No single point of failure and no coordinator — every node can serve any request.
•Tunable consistency: the caller chooses R and W per operation.

Back-of-the-Envelope Math

100 TB logical * 3 replicas = 300 TB raw; at 4 TB per node, ~75 nodes plus headroom.
N=3, W=2, R=2 gives R+W>N (read-your-writes) while tolerating one replica being down.

Key Architectural Trade-offs

Quorum tuning: W=N is durable and fragile; W=1 is always writable and lets reads go backwards — the CAP dial made concrete.
Conflict resolution by last-write-wins (simple, silently loses data under clock skew) vs vector clocks with client-side merge (correct, pushes work to the caller).
Anti-entropy via Merkle-tree comparison is cheap in bandwidth and expensive in CPU; read-repair fixes only what's actually read.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow