The deep dive
Fifteen minutes on the parts of the design that can break under load: where each key lives, what happens when one key is wanted by everyone, how data moves when a node joins, what sits on the disk, and how fresh a read is. Every choice gets a mechanism and a price said out loud.
What should I go deep on if the interviewer does not say?
The part of the design the requirements stress hardest, and you say why you picked it. On a store that must never lose a write, that is replication and the quorum. On a feed at hundreds of millions of users, it is the shard key and the hot celebrity. Name two candidates, pick one, and give the reason in a sentence, so the interviewer can redirect you before you spend five minutes.
Why is hash modulo the node count a bad way to shard?
Because adding one node changes the answer for almost every key. Counted on ten thousand key names going from thirty nodes to thirty-one, the modulo moves 9.71 thousand of them, while a ring with a hundred virtual nodes a node moves 309, close to the new node's fair share. On the key-value store's six stored terabytes, that is the difference between copying 5.83 terabytes and copying 0.19.
How do I handle a hot key in a system design interview?
Say first that consistent hashing does not help, because one key lands on one owner however you hash it. Then climb the ladder only as far as the numbers force you: cache the hot value and add read replicas, split the key into salted sub-keys, aggregate locally before writing, give the key its own partition, and coalesce duplicate requests with back-pressure at the edge. Detect it with a per-partition request-rate metric, not the cluster average.
LSM tree or B-tree: which should I pick?
Ask whether the workload is write-heavy. A log-structured merge tree turns every write into an append and pays for it later in compaction and in reads that may check several files; a B-tree updates pages in place and gives the steadier point read. Pick the LSM when writes dominate, as they do at the replicas of a store that writes three copies, and the B-tree when reads and in-place updates dominate, as in most relational workloads.
What does W + R > N mean?
N is the number of copies of a key, W is how many must confirm a write before it counts, and R is how many a read asks. When W plus R is more than N, every read set shares at least one replica with every write set, so a read meets the latest acknowledged write. W greater than N over two adds that two conflicting writes cannot both reach a quorum on disjoint replicas.