Question bank — Distributed databases — sharding strategies, replication

False — sharding splits distinct data for scale, while replication copies the same data for survival; they are orthogonal and real systems use both. See Horizontal vs Vertical Partitioning.

False as stated — a row has exactly one primary shard, but replication means copies of that row can exist on several nodes; "one shard owns it" ≠ "one physical machine has it."

False — it spreads point writes evenly, but range queries scatter across every shard, so a range-heavy workload still suffers even without a write hotspot.

False — it still moves about $\frac{1}{N+1}$ of keys (the new node's arc, i.e. its slice of the ring); it just avoids the near-total reshuffle of naive mod N. See Consistent Hashing.

Mostly true for synchronous quorum writes — the read set $S_R$ is forced to overlap the latest write set $S_W$ — but with sloppy quorums or in-flight concurrent writes you can still read an old-but-valid version; the guarantee is "you see a value at least as new as the last completed write."

False — raising $N$ forces you to grow $W$ and $R$ to keep $W+R>N$, adding latency; safety is governed by the quorum relation, not raw replica count. See Quorum Consensus and Paxos/Raft.

True for the acked writes — the leader waits for a follower's confirm before it acks (tells the client "done") — but it stalls the whole system whenever that follower is slow or down, trading availability for durability.

True — with exactly one writer (the leader) there is no way for two conflicting versions of a row to be accepted concurrently, which is precisely why it's the simplest topology.

False — the hash quality isn't the issue; the problem is that % N ties every key's home to the value of $N$, so scaling out reshuffles almost everything.

False — CAP only forces the choice during a network partition; when the network is healthy you can have both. See CAP Theorem (and the triangle sketch below).

The error is the hotspot: time-ordered keys all land in the newest range, so every incoming write hammers one shard while the others sit idle (see the hotspot figure below).

Wrong — $1+1=2\ngtr 3$, so the write set $S_W$ and read set $S_R$ can miss each other entirely and the reader may see a stale value.

The error is cost: under naive mod about $\frac{N}{N+1}=\frac{4}{5}$ of keys change their remainder (residue class), so ~80% of the dataset must physically move.

It ignores the cost: two leaders can accept edits to the same row, producing write conflicts that need explicit resolution logic the single-leader design never faces.

The error is replication lag: the leader acks (says "done") before followers copy, so a crash in that window loses the last un-replicated writes.

It gives the safest durability but zero write fault tolerance — if any one of the $N$ replicas is down, no write can reach all $N$ and so no write can complete at all.

With a single point per server, the arcs (each server's ring slice) are wildly uneven, so load and the data-to-move on failure are lopsided; virtual nodes exist to smooth the arcs. See Consistent Hashing.

Not with asynchronous replication — the follower may lag behind, so it can return an older value than a just-completed write (the read-your-writes problem). See Replication Lag and Read-Your-Writes.

Because a key stays put only if $hash(k)\mathrm{mod}N=hash(k)\mathrm{mod}(N+1)$; since $hash(k)$ acts like a random number, landing back in the same one of the $N+1$ possible remainders happens with probability only about $\frac{1}{N+1}$ — so nearly all keys land in a new bucket. See Hash Functions.

The overlap size of the two groups is $|S_W\cap S_R|\ge W+R-N$; for a guaranteed shared replica ($\ge 1$) we need $W+R-N\ge 1$, i.e. $W+R>N$. Equality $W+R=N$ allows the sets to be disjoint (touch zero common boxes).

Range sharding keeps contiguous keys together so the query touches few shards; hashing deliberately scatters neighbours across all shards, so a range scan must query every one.

A partitioned node can't confirm with its peers, so it must either refuse to answer (keep C, lose A) or answer with possibly-stale data (keep A, lose C). See CAP Theorem.

The read set $S_R$ may return several copies at different versions; version numbers let the reader identify the newest one among them, which the quorum overlap guarantees is present.

Because sharding already split the data for scale; replicating each shard preserves that scale while adding survival — copying the whole thing again would defeat the sharding. See Load Balancing.

About $\frac{1}{N+1}=\frac{1}{2}$ of keys move — with only two nodes the ring splits into two arcs of roughly half each, so a large fraction moving is expected, not a bug.

Any $W\ge 1,R\ge 1$ satisfies $1+1>1$, but there is no fault tolerance and no read scaling — the "quorum" is trivial and the node is a single point of failure.

The leader can no longer get its confirmation, so writes stall until the follower recovers or is dropped from the sync set — availability suffers precisely because durability was prioritised.

A system that requires all replicas for both reads and writes — maximally consistent but with zero fault tolerance and the worst latency; correct but usually impractical.

No — a good hash destroys the ordering, so sequential keys scatter uniformly; the hotspot is a property of range sharding on ordered keys, not of the data alone. See Hash Functions.

About $\frac{1}{N}$ — the departing node's single arc is handed to its clockwise neighbour, mirroring the add case.