Multiple-choice synthesis across the data-distribution unit: replication lag and lost writes, partitioning strategies and the hot shard, consistent hashing vs mod-N, and the CAP/PACELC choice per use case.
SDSenior◷ 13 min
Level
FoundationsJuniorMiddleSenior
Six questions that cut across the whole unit. Each is a decision you make when you choose a replication mode, pick a partition key, route keys to nodes, or label a data store’s consistency — not a definition to recite, but the trade-off a senior engineer commits to under a real failure.
Confirm you can trace a lost write through an async failover, diagnose a hot shard from a partition key, pick consistent hashing over mod-N, compute a quorum overlap, and place a workload on the consistency spectrum with CAP and PACELC straight.
Quiz
Completed
An async-replicated database acknowledges writes #51–53 to clients, then the leader crashes having shipped only up to #50. A follower at #50 is promoted. What is the correct description?
Heads-up Clients don't hold a replayable log of acknowledged writes, and the database never asked them to. The writes existed only on the dead leader and are gone. Durability needs a synchronous replica, not client replay.
Heads-up That's the trap: with async replication the ack is sent before the write is durable anywhere but the leader. A crash in that window loses acknowledged writes silently.
Heads-up Eventual consistency is about reads converging, not about recovering writes that were never replicated. #51–53 left no copy to converge to; they're lost.
Quiz
Completed
You shard users by user_id, evenly by count. One shard pins at 100% CPU while the rest idle, right after a celebrity account went viral. What's happening, and the cleanest mitigation?
Heads-up Counts are already even — the problem is LOAD concentrated on one hot key, not row distribution. Rebalancing counts won't move the celebrity's traffic off its shard.
Heads-up This is a hot-key load problem on one shard, not replication. More followers scale reads broadly but don't relieve the single key whose traffic all routes to one shard.
Heads-up Range wouldn't help — the celebrity's single key still lands on one shard regardless of scheme. You must spread that key specifically: split it, cache it, or isolate it.
Quiz
Completed
A Redis cache fleet routes keys with hash(key) mod N. Adding one node (N: 16 → 17) collapses the hit rate to near zero. What's the fix and why does it work?
Heads-up With mod-N, changing the divisor remaps NEARLY ALL keys, so essentially every lookup misses — not just the new node's share. Pre-warming one node can't fix a fleet-wide remap; consistent hashing prevents it.
Heads-up Replicas don't change the routing function; the collapse is from mod-N remapping every key on the N change. The structural fix is consistent hashing, which decouples routing from N.
Heads-up Longer TTLs don't help when every key now hashes to the wrong node — the entries exist but are looked up on the wrong node. Consistent hashing keeps keys on their node when membership changes.
Quiz
Completed
A leaderless store has N = 5 replicas. You want a read to be guaranteed to see the latest acknowledged write. Which (W, R) pair achieves this with the most write availability?
Heads-up R + W = 2 is not > N = 5, so the read and write sets can be disjoint — the read may miss the latest write entirely. The overlap guarantee requires R + W > N.
Heads-up R + W = 10 > 5 does guarantee overlap, but W = 5 requires every replica for a write — the least write availability, the opposite of the goal. W = 3, R = 3 also overlaps with more write headroom.
Heads-up R + W = 4 is not > 5, so the sets may not overlap and a read can miss the latest write. You need the sum strictly greater than N; the minimum here is 6, e.g. W = 3, R = 3.
Quiz
Completed
A teammate says 'we run Cassandra, so we're AP — we gave up consistency.' Using CAP and PACELC precisely, what's the most accurate correction?
Heads-up Cassandra offers tunable consistency (quorum levels per query); it isn't 'no consistency'. And AP is only the partition-time stance — the everyday trade-off is latency vs consistency (PACELC's else), which the statement omits.
Heads-up Cassandra leans AP under partition (it stays available, serving possibly-stale reads). The correction isn't to flip the letter but to note that AP describes only the partition case, and PACELC's EL describes the rest.
Heads-up They're not: CAP covers only the partition-time C-vs-A choice; PACELC adds the else-branch (latency vs consistency in normal operation), which is exactly what the teammate's statement ignores.
Quiz
Completed
You're choosing a consistency level per data type for one product. Which assignment reflects the unit's 'pick per use case' principle?
Heads-up Demanding linearizability on a like count or feed buys the latency and reduced availability of CP/EC for data that doesn't need it, making the whole product slower and more fragile under partition for no benefit.
Heads-up Running a balance or inventory on an eventually-consistent store invites double-spends and oversells during a partition. Money and inventory need linearizability; only low-stakes data should be eventual.
Heads-up Read-your-writes is a per-client guarantee, too weak for a balance (which needs global linearizability) and overkill for a public like count (eventual is fine). One level for everything is the mistake.
Recall before you leave
01
Why can an async-replicated failover lose acknowledged writes, and what prevents it?
02
Give the minimum quorum for a guaranteed-fresh read with N = 5 and the most write availability.
Recap
The through-line is that distributing data is a series of choices about which disagreement you can tolerate. Replication copies data for reads and survival, but async replication acks before durability, so a failover can lose acknowledged writes — keep a synchronous replica. Sharding splits data by a partition key, and an even key count still produces a hot shard under skew (the celebrity), fixed by splitting, caching, or isolating the hot key. Consistent hashing routes keys on a ring so adding a node moves only ~1/N of keys, where hash mod N would remap nearly all of them and wipe a cache. Leaderless quorums guarantee a fresh read when R + W > N (the read and write sets overlap). And CAP is only the partition-time C-vs-A choice while PACELC adds the everyday latency-vs-consistency trade — so you pick per use case: linearizable for money and inventory, eventual for like counts and feeds, read-your-writes for a user’s own edits.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.