The brief
Store and serve keys across many nodes with tunable consistency. Your design should meet these requirements:
- Clients can get, put, and delete values by key.
- The store survives the loss of individual nodes without losing acknowledged writes.
- Capacity grows by adding nodes without a full reshuffle.
Scale to design for
A Dynamo-style store: get/put/delete by key, survives node loss without losing acknowledged writes, scales by adding nodes.
State these assumptions out loud in the interview, then let them drive your choices: they decide what needs caching, sharding or asynchronous processing.
Before you start
You'll get more out of this round if you're comfortable with:
- Consistent hashing
- Replication and quorums
- CAP and consistency models
- Gossip and failure detection
Questions an interviewer may ask
Expect follow-ups like these once your high-level design is on the board. Have an answer, and a reason, for each:
- With N=3, W=2, R=2, what happens when one replica is down?
- Two clients write the same key concurrently: what is stored?
- How do replicas that missed writes catch up?
- How does adding a node move data?
Common mistakes to avoid
- Acking writes before they're durable
- Modulo partitioning
- No story for conflicting concurrent writes
- No repair of divergent replicas
Concepts this round covers
- Consistent hashing
- Quorum reads and writes
- Conflict resolution
- Replication
What a complete answer covers
A partitioning and replication scheme, read/write quorum choice, failure detection and repair, and the consistency guarantees clients get.
There is no single correct design. A strong answer meets the requirements at the stated scale and explains the trade-offs behind each choice. New to the format? Read how to prepare for a system design interview.