Visual walkthrough — NoSQL — document (MongoDB), key-value (Redis), column (Cassandra), graph (Neo4j)
We are going to earn every symbol. Before we use , , or , we draw them.
Prerequisite ideas we lean on: Sharding and Replication (why there is more than one copy), CAP Theorem (why nodes sometimes can't talk), and BASE vs ACID (why "eventually" is a choice). This is the deep dive for the parent NoSQL note.
Step 1 — What is a replica, and what is ?
WHAT. A single piece of data — say the number stock = 7 — is not stored in one place. To survive
a machine dying, the database keeps several identical copies on different machines. Each copy is
called a replica. The letter is simply how many replicas we keep.
WHY. One copy = one point of failure. If that disk dies, the data is gone. So distributed stores (Cassandra, DynamoDB) copy each value onto machines. Here we pick to have room to count.
PICTURE. Five boxes in a row. Each box is one machine holding one copy of the same value.
Step 2 — What is a write, and what is ?
WHAT. A write is a client saying "change the value to 8". In a replicated system the client
sends this update toward the replicas. But the network is slow and machines are busy, so the client
does not wait for all of them to confirm — it waits for a chosen number to say "got it, saved".
That number is : the write quorum, how many replicas must acknowledge before we call the
write a success.
WHY. Waiting for all is slow (the slowest machine drags everyone). Waiting for fewer is faster but riskier. is the dial. In our picture we set .
PICTURE. The new value 8 (yellow) lands on exactly boxes. Those three now hold the fresh
value; the other two still hold the old 7 (they'll catch up later — that's the "eventually" in
eventual consistency).
Step 3 — What is a read, and what is ?
WHAT. A read is a different client asking "what is the value now?". It does not ask all replicas either — it asks of them, collects their answers, and picks the newest. is the read quorum: how many replicas we contact for a single read.
WHY. Same reasoning as writes: asking all is slow, asking one is fast but might hit a stale box. is the read dial. We choose .
PICTURE. A reader (green outline) touches boxes. It has no idea which boxes are fresh — it just grabs 3 of the 5 and looks at what they hold.
Step 4 — The whole danger, in one question
WHAT. Put Step 2 and Step 3 on the same picture. The write set (yellow) is boxes that are fresh. The read set (green ring) is boxes we look at. The danger is simple:
Could the reader pick boxes that are all stale — i.e. entirely miss the fresh boxes?
If yes, the reader returns the old 7 even though 8 was already written. That is stale data.
WHY. A read is only guaranteed correct if the green ring is forced to include at least one yellow box. So the entire proof reduces to a counting question: can the read set dodge the write set?
PICTURE. A "bad case" attempt — reader tries to place its 3 green picks only on blue boxes.
Step 5 — Pigeonhole: when can two sets NOT avoid each other?
WHAT. We have boxes total. We colour of them yellow. The reader must pick boxes. Question: how many "safe" (non-yellow) boxes exist for the reader to hide in?
Non-yellow boxes .
The reader needs boxes but only safe boxes exist. It cannot fit 3 picks into 2 safe slots — by the pigeonhole principle, at least one pick lands on a yellow box.
WHY (this is the heart). This is the pigeonhole idea: if you must place items into only safe slots and , at least one item spills into the unsafe (yellow) region. That spilled pick is the fresh copy the reader needed.
PICTURE. Left: picks vs only safe slots → one pick forced onto yellow (overlap!). Right: the same counting shown as two overlapping bars.
Step 6 — Read it back: the size of the guaranteed overlap
WHAT. Overlap isn't just "≥ 1 exists" — we can count exactly how many boxes are guaranteed shared. The read set and write set together name box-slots, but only distinct boxes exist, so the number forced to be shared is
WHY. With : overlap . Exactly one box is guaranteed to be in both sets — and that box holds the newest value. A version/timestamp on each answer lets the reader pick it out.
PICTURE. The two sets drawn as overlapping regions; the shaded sliver of width is labelled "always fresh".
Step 7 — The degenerate & edge cases (never leave the reader stranded)
WHAT. We check every boundary so no scenario surprises you.
Case A — exactly (e.g. ). Safe boxes , reader needs . It can fit exactly into the 3 safe boxes → disjoint sets possible → can miss the write. So equality is not enough; we need strictly greater (), which is why the parent wrote and not .
Case B — . . Reader easily dodges the single fresh box. This is fast but eventually consistent — exactly the BASE tradeoff.
Case C — (write to all). Every box is fresh; even overlaps. Strongest, slowest writes. Case D — (read all). Symmetric: even is safe, but reads are slow.
Case E — a node is down (a partition, from CAP Theorem). If fewer than boxes are reachable, the write cannot complete — the system refuses (chooses Consistency) or relaxes (chooses Availability). This is precisely CAP surfacing inside the quorum dial.
PICTURE. Four mini-panels: equality (dodges), (dodges), write-all (always safe), node-down (write blocked).
Step 8 — Worked numbers (from the parent, now visibly true)
The one-picture summary
This single figure compresses all eight steps: the total boxes, a write colouring of them, a read touching of them, and the pigeonhole sliver that must be shared when — and only when — .
Recall Feynman retelling — say it like you'd tell a friend
Imagine 5 lockers, each holding a copy of the same note. When I update the note I only bother to change 3 lockers () — that's faster than opening all 5. Later you want to read it, so you open 3 lockers () and trust the one with the newest date stamp. Here's the trick: I changed 3, you open 3, but there are only 5 lockers total. There are just lockers I didn't touch. You're opening 3 lockers into only 2 "old" hiding spots — you physically can't avoid opening at least one locker I updated. That guaranteed shared locker is . So you always see my change. If instead we'd set , I change 1 locker, you open 1 — easy to miss each other, and you might read the old note for a while ("eventually consistent"). The whole law is just: make the two handfuls too big to dodge one another.
Recall Quick self-test
Why must the inequality be strict () and not ? ::: At the read set can fit exactly into the stale boxes, missing the write. Only forces overlap . What does the quantity mean? ::: The number of replicas guaranteed to be in BOTH the read and write sets — the boxes that certainly hold the fresh value. — strong or eventual? ::: ; overlap → eventual (edge equality case, not strict).