EN δΈ­ζ–‡

System Design Lab

A distributed key-value store trades consistency, latency, and availability by tuning how many replicas must agree.

Change throughput, key count, value size, replication factor N, read quorum R, write quorum W, and cluster size. The design moves from a single node to a consistent-hash ring, to replication, to quorum tuning (the CAP tradeoff made concrete), and finally to multi-region with anti-entropy. This mirrors Amazon Dynamo and Apache Cassandra.

Read the full tutorial

Guided walkthrough

Reason about it one step at a time

Each step sets the workload below - watch the diagram, meters, and decisions react.

Normal evolution scenarios

Click left to right for the intended demo path. Each card changes the workload inputs.

Workload

These are inputs, not preset architecture stages.

Recommended shape

Current architecture path
Distributed key-value store architecture diagram Whiteboard-style architecture diagram for a Dynamo-style key-value store: clients, a coordinator that hashes the key onto a ring, partitions on a consistent-hash ring, the N replica nodes that hold each key, and an async anti-entropy layer of gossip membership and read repair. Clients Coordinator Hash ring Replicas Anti-entropy Client get + put Coordinator hash + route Quorum logic R + W gate Consistent ring virtual nodes Primary replica first owner Extra replicas next N-1 nodes Hinted handoff failover writes Gossip membership Read repair heal divergence
Clients
Client issues get and put operations keyed by an opaque key
Coordinator
Coordinator hashes the key, finds its position on the ring, and fans the request out to replicas
Quorum logic waits for R reads or W write acks before answering the client
Hash ring
Consistent ring maps key hashes to partitions; virtual nodes keep load balanced as the cluster changes
Replicas
Primary replica the first of the N nodes responsible for a key on the ring
Extra replicas the next nodes clockwise that each hold a copy for durability and availability
Hinted handoff a stand-in node temporarily stores writes for a down replica and replays them later
Anti-entropy
Gossip nodes exchange membership and health so the ring converges without a master
Read repair reconciles stale replicas found during reads and via background Merkle-tree syncs

Bottlenecks

Per-node op load

Storage per node

Write amplification

Quorum / consistency

Cross-region + anti-entropy

Why this changes

    Decision tradeoffs

    Partitioning

    Replication factor

    Quorum tuning

    Conflict resolution

    Failure handling

    Membership

    Source-backed rules

    These are the durable system-design claims behind the model. The exact slider thresholds are deliberately labeled as teaching assumptions.

    Verified rule

    Consistent hashing partitions keys and limits reshuffling on membership change

    Dynamo places keys on a ring by hash and uses virtual nodes so that adding or removing a node only moves a fraction of the keys, keeping load balanced.

    Amazon Dynamo (SOSP 2007)
    Verified rule

    Quorum R+W>N gives read-your-writes; smaller quorums favor latency and availability

    Dynamo exposes N, R, and W as tunable knobs; R+W>N makes the read and write sets overlap so a read sees the latest write, trading off latency and availability.

    Amazon Dynamo (SOSP 2007)
    Verified rule

    Hinted handoff and read repair keep the store available and eventually consistent

    Cassandra stores hints for unreachable replicas and repairs divergence during reads and via background anti-entropy, so failures do not block writes.

    Apache Cassandra Docs
    Verified rule

    DynamoDB is a managed key-value store with tunable, region-scoped replication

    DynamoDB offers eventually and strongly consistent reads and global tables that replicate across regions, the same N/R/W tradeoffs as a managed service.

    AWS DynamoDB

    Teaching assumptions

    • Per-node op and storage budgets are conservative teaching numbers; real nodes vary widely by hardware and value size.
    • Write amplification is modeled simply as the replication factor N β€” every put is applied to N replicas.
    • Consistency pressure compares R+W to N; it abstracts away clock skew, sloppy quorums, and hinted writes.