How would you design a distributed key-value store?
219 views
88 of 106
1
The problem
Question presented to candidate:
"Design a distributed key-value store like Amazon Dynamo, Cassandra or Riak. It stores get(key) and put(key, value) for many terabytes of data across many machines, stays available when machines fail, and lets each application choose how consistent its reads should be. Walk me through partitioning, replication, failures and how each node stores data on disk."
What a strong answer should cover:
The CAP decision up front: an AP, leaderless Dynamo-style design with tunable consistency, versus a CP design with a leader per shard (Raft), and when each fits
Partitioning with consistent hashing and virtual nodes; replication to the next N distinct nodes on the ring (the preference list)
Quorums: N, R, W and R + W > N; sloppy quorum with hinted handoff to stay writable during failures; read repair and Merkle-tree anti-entropy to converge
Conflict handling: vector clocks and siblings versus last-write-wins, and what LWW silently loses
Membership and failure detection by gossip, and the storage engine: write-ahead log, memtable, SSTables with Bloom filters, tombstones and compaction
Worked numbers: node count from data size, replication and headroom; per-node write rate
Clarifying questions expected:
Value sizes and data volume? Read-heavy or write-heavy?
Is eventual consistency acceptable, or do some operations need linearizable reads or compare-and-set?
Single region or multi-region? Expected failure modes?
Code / implementation expected: Optional โ the examples run a Dynamo-style cluster (ring, sloppy quorum, hinted handoff, read repair, vector clocks) and an LSM storage engine on one node.
key-value-store
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers preparing for the classic "design a key-value store" round, which tests whether you can combine partitioning, replication, consistency and storage into one coherent system.
Difficulty: Hard
Verified with: Node 22.22, Python 3.12, Go 1.24 and Java 21 for the cluster example (identical output); Node 22.22 and Python 3.12 for the storage-engine example. The design follows the Dynamo paper (DeCandia et al., SOSP 2007); the DynamoDB 400 KB item limit is from the AWS DynamoDB developer guide.
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the words an interviewer expects. Every number comes from running the examples; the Verified section quotes their full output. Several building blocks have their own pages and are only summarised here: [What is consistent hashing?]
The solution is hidden so you can try first
20 min read ยท 16 sections
4
Read the code
Dynamo-style cluster: ring placement, sloppy quorum with hinted handoff, read repair and vector-clock siblings