Case Studies
Key-Value Store
A Dynamo-shaped storage primitive: consistent-hashing partitioning, quorum replication, and vector-clock conflict resolution.
Designing the storage primitive itself — a Dynamo-shaped distributed key-value store with partitioning, replication, and tunable consistency — rather than "which database would you use" for a higher-level product. This is the interview that tests whether a candidate actually understands what a database like Cassandra or DynamoDB is doing underneath, not just how to call one.
What this lesson covers
Partition keys on a consistent-hashing ring with virtual nodes, replicate each key to N nodes, and use quorum reads and writes with W + R > N (N=3, W=2, R=2). Resolve concurrent versions with vector clocks rather than last-write-wins, and detect failures with gossip.
- The interface is just put(key, value) and get(key); the hard part is many nodes each holding a slice with backup copies nearby.
- Scope it as a storage primitive: horizontal scale, survive node loss without losing data, and operator-tunable consistency.
- The key trade-off is how many replicas must acknowledge a write or answer a read, and what that costs in availability.
- Concurrent writes across a partition force a conflict-resolution choice; last-write-wins is simpler but silently loses data.
- A senior answer explains why a read is guaranteed to see the latest write; staff adds how a rejoining node catches up.
Included in Plus and Pro
Continue reading “Key-Value Store”
The full lesson works the design through end to end — diagrams, trade-offs, and what interviewers expect at each level. About 21 minutes.
- Understanding the Problem
- Functional Requirements
- Non-Functional Requirements
- Capacity Estimation
- Core Entities
- API Interface
- High-Level Design
- Trade-offs
- Final Design
- Operations & Observability
- Level Expectations
- Follow-Up Questions
- Try It Yourself