← All parts

End-to-End Design

Design a Distributed Key-Value Store · Part 3
Problem context

Design a horizontally-scalable key-value store — get(key) / put(key, value) — that stays available and low-latency while spread across hundreds of nodes and multiple datacenters. It must survive node and network failures without downtime, scale storage and throughput by adding machines, and offer a defensible answer to "what does a read return after a write that raced a partition?"

This is the Dynamo / Cassandra / Riak lineage — a leaderless store (no single node orders writes; any node can accept one) that is eventually consistent, with consistency tunable per request (each call chooses how many replicas must agree). In scope: spreading keys and their replicas across nodes, reads and writes that stay available during failures with per-request consistency, reconciling versions that diverged, recovering after a node was unreachable, tracking cluster membership, and the on-disk storage engine. Out of scope: secondary indexes and range scans, rich schemas, single-leader strong-consistency designs, and multi-key transactions.

What a strong answer sounds like

State the decision, connect it to a requirement, and name the tradeoff. Keep the design focused on the workload in the prompt.

Ready for the end-to-end design interview?

The AI interviewer asks about this part of Design a Distributed Key-Value Store. The interviewer guides you through topics one by one.