4.4.27 · D2Databases

Visual walkthrough — Distributed databases — sharding strategies, replication

2,140 words10 min readBack to topic

This page is the visual companion to the parent topic. If a word feels new, we define it the moment it appears.


Step 1 — What is a "replica" and what does count?

WHAT. Imagine your data — say the row user 42 → balance $100 — living not once but as several identical copies. Each copy sits on its own machine. One such copy is called a replica. The total number of replica machines we write the same row to is the number .

WHY start here. Every symbol in counts replicas. Before we can compare , , and , we must agree that they all measure the same kind of thing: boxes that each hold a full copy of the row. is simply how many boxes there are in total.

PICTURE. Below, boxes stand in a row. They are identical in shape because each stores the same row. Right now none is special — that comes next.

Figure — Distributed databases — sharding strategies, replication

Step 2 — A write is "touching" a subset of the boxes

WHAT. When a client writes the new value balance $100 → $150, it does not always update all boxes. It updates of them and then tells the client "done". The chosen boxes are the write set, written . "Set" here just means the group of boxes we touched — nothing fancier than colouring some boxes in.

WHY a subset and not all. If we insisted on updating all every time, a single dead box would freeze every write. Touching only boxes lets writes survive some failures. So is a tunable dial for write fault-tolerance.

PICTURE. Here and . The three red boxes are — they now hold the fresh value \150$100$; the write did not reach them yet.

Figure — Distributed databases — sharding strategies, replication

  • — the group of boxes the write updated (the red ones).
  • — the size of that group, i.e. how many boxes are in it; the two vertical bars mean "count the elements".
  • — the number we chose; here .

Step 3 — A read also touches a subset

WHAT. To read, the client asks boxes for their copy. That group is the read set , with . The reader collects whatever values those boxes report.

WHY only and not all. Same reason as writes: asking every box would stall on a single slow machine. is the read fault-tolerance / speed dial.

PICTURE. Same 5 boxes. The write from Step 2 left boxes 1–3 fresh (we redraw them lightly). Now a read with asks boxes 4 and 5 — the red-outlined ones. Notice the danger: both of those boxes are stale. The reader would answer \100$150$.

Figure — Distributed databases — sharding strategies, replication

Step 4 — The whole question: must the two sets share a box?

WHAT. We have two coloured groups inside the same boxes: (freshly written) and (just read). A read is guaranteed fresh iff at least one box belongs to both groups — because that shared box carries the new value into the read.

WHY "iff overlap". If the groups touch, the reader sees the new value in the shared box and (using version numbers) keeps the newest — fresh guaranteed. If they can be made disjoint, then in the worst case the reader sees only stale boxes — no guarantee. So the entire problem reduces to one geometric question: can these two coloured regions be pried apart inside boxes?

PICTURE. Two scenarios side by side. Left: and overlap in the red shared box — the read sees fresh data. Right: they are disjoint — the read misses the write.

Figure — Distributed databases — sharding strategies, replication

Step 5 — Pigeonhole: when are two subsets forced to overlap?

WHAT. We now find the exact condition on the numbers , , that makes overlap unavoidable, no matter how an adversary places the sets. This is a counting argument called the pigeonhole principle: if you try to fit more items into slots than there is room to keep them separate, some must collide.

WHY this tool and not another. We don't want a rule of thumb — we want a guarantee against the worst case. Pigeonhole is exactly the tool that answers "is separation impossible?" rather than "is overlap likely?". Probability would only give "usually"; pigeonhole gives "always".

PICTURE. Picture the boxes as a line of length . Lay the write-boxes as far left as possible and the read-boxes as far right as possible — the adversary's best attempt to keep them apart. If exceeds , the two blocks physically cannot fit without a box doing double duty (shown in red as the forced overlap).

Figure — Distributed databases — sharding strategies, replication

Formally, the minimum possible overlap of a -subset and an -subset inside an -set is:

  • — total "box-slots demanded" if we could keep them separate.
  • — total slots available.
  • — the spill-over: how many demands cannot find their own private slot and are forced to share. If this is the blocks fit apart; if it is they must overlap.

Step 6 — Combine: the boxed rule falls out

WHAT. We required overlap (Step 4). Pigeonhole says the guaranteed overlap is at least (Step 5). To force the guarantee, set the guaranteed minimum to satisfy our requirement:

  • — "the forced overlap is at least one box."
  • — "means exactly the same as."
  • — strictly greater; add to both sides of to get , which for whole numbers is the same as .

WHY strictly greater and not . If exactly, the spill-over is — the adversary can line the blocks up disjointly (the failing right-hand case of Step 4). Equality is not enough; we need to tip past .

PICTURE. A number line for . Everything left of the line "" (like ) is the unsafe zone; everything strictly right (like ... no — , or ? watch out) is safe. The red mark sits at the boundary , the exact place where the guarantee is born.

Figure — Distributed databases — sharding strategies, replication

Step 7 — Every case, checked against the rule

WHAT. We test the three configurations the parent note named, plus the degenerate extremes, so no scenario surprises the reader. Take .

? Meaning
strong + tolerates 1 node down on both sides (default)
reads super-fast; writes fail if any node is down ()
writes fast; reads must hit all → no read fault-tolerance
fast but can read stale — sets may miss entirely

Degenerate cases (WHY they still obey the rule):

  • : ✓ always — but a single dead replica blocks all writes. The rule guarantees freshness, not availability.
  • : mirror image — reads become fragile.
  • (write acknowledges touching nothing): then , the write set is empty, overlap is impossible — no read is ever fresh. The rule needs , impossible, correctly flagging this as broken.

PICTURE. The safe region drawn as a shaded triangle on a grid for : the red line is the border, the shaded corner above it is every legal quorum, the three example dots sit inside it and the stale dot sits below.

Figure — Distributed databases — sharding strategies, replication

The one-picture summary

Figure — Distributed databases — sharding strategies, replication

The whole derivation in one frame: boxes, a red write set of size pushed left, a read set of size pushed right, and the red forced-overlap box that appears precisely when crosses . That single shared box is the entire guarantee.

Recall Feynman retelling — explain it to a friend in plain words

We keep several identical copies of a row on separate machines — call the count . When we save a change, we don't bother updating all of them; we update and stop. When we read, we ask of them and take the newest answer. Now here's the only trick: a read is guaranteed to see the newest write only if the group we wrote and the group we read are forced to share at least one machine — because that shared machine is the messenger carrying the fresh value. Whether they're forced to share is pure counting: two blocks of sizes and shoved into slots can only stay apart while fits inside . The instant pokes past , at least one slot must serve both — overlap becomes unavoidable — and freshness is guaranteed. That is all says. Bump up by adding replicas and you must read or write more to keep the sum above , which is why "more copies" is not automatically "safer".

Recall Quick self-test

Why is (equality) not safe? ::: Forced overlap is , so the sets can be made disjoint — a read may land entirely on stale replicas. What principle forces the overlap? ::: The pigeonhole principle: two subsets of sizes summing past cannot fit inside slots without sharing one. With , is safe? ::: ✓ yes, overlap .


Related: CAP Theorem (why you sometimes choose to break the quorum for availability), Replication Lag and Read-Your-Writes (what stale reads feel like in practice), and back to the parent topic.