Two different moves for two different pains
Replication means keeping full COPIES of the same database on several machines: one primary takes all the writes, and every change it makes is streamed to replicas that hold the same data moments later. Sharding means SPLITTING the data instead: each machine (shard) holds a different slice — customers A–H here, I–P there — and no machine holds everything.
They cure different pains, and mixing them up is the classic interview stumble. Replication cures "too many reads" (spread them over copies) and "what if the machine dies" (a copy is a ready spare). Sharding cures "too many writes" and "the data no longer fits one machine" — the only cure, because copies do not shrink anything.
A useful memory hook: replication is a photocopy, sharding is a filing cabinet split across rooms. Photocopies help more people read at once and survive a fire; splitting the cabinet is what you do when it stops fitting in one room.
- primary
- — the one copy that accepts writes
- replica
- — a live full copy, kept in sync, serving reads
- shard
- — one machine holding one SLICE of the data
- shard key
- — the field that decides which shard a row lives on
Words to know
One database, two very different problems
SliceNow's cache handles the menu, but everything the cache cannot hold — order histories, driver positions, account pages — still reads from ONE database doing 900 queries/sec of its ~1,000 capacity. And the on-call engineer has started losing sleep over a darker number: if that one machine dies, SliceNow is offline until it is rebuilt.
One move fixes both: add two replicas. The primary keeps taking every write and streams each change to the copies (they lag behind by 50-500 milliseconds — remember that number, it stars in the consistency lesson). The app sends its READS to the replicas and only writes to the primary. Read load per machine drops to ~300/sec — and if the primary dies, a replica is promoted and the outage lasts a minute, not a day.
Sharding is NOT needed yet — and that matters. Writes are a modest 80/sec and the data fits on one machine with room to grow. The interview-grade answer is knowing the order: cache first, then replicate, and shard only when writes or size demand it — because sharding is the move you cannot easily undo.
Reads before
900/sec on one box
With 2 replicas
~300/sec each
Replication lag
50–500 ms
Quick check
A photo-sharing app ingests 40,000 uploads per second and the write volume has crushed the primary. Replicas are already in place. What actually helps?
Sharding, traced: which room does the row live in?
When SliceNow eventually shards orders across 4 machines, every read and write starts with the same tiny step: compute which shard owns the row. A common recipe: take the customer_id, hash it to a number, take the remainder mod 4. Customer 88 → hash → 2,347,113 → mod 4 = shard 1. Every one of customer 88's orders lives on shard 1, forever.
Now "orders for customer 88" touches exactly ONE machine holding a quarter of the data — the other three shards never hear about it. Four shards ≈ 4× the write capacity and 4× the storage headroom.
The catch: questions that do not include the shard key must ask every room. "All orders over $100 today" fans out to all 4 shards and merges the answers. This is why the shard key is THE design decision: pick the field your hottest queries already filter by.
Replicate or shard — match the cure to the pain
Say the pain out loud first; the move picks itself.
| The pain | The cure | Why |
|---|---|---|
| Reads overwhelm one machine | Replication | Copies share the read load |
| That machine dying = total outage | Replication | A replica is a hot spare, promoted in seconds |
| Writes overwhelm one machine | Sharding | Each shard takes only its slice of writes |
| Data no longer fits one machine | Sharding | Splitting is the only thing that shrinks a slice |
| Both at massive scale | Shard, then replicate each shard | Big systems do both: slices for writes, copies per slice for reads & safety |
Common trap — The hotspot: a shard key that betrays you
Shard a food-delivery app by CITY and the New York shard melts every lunch rush while the Boise shard naps — uneven keys make uneven shards, and one overloaded shard hurts exactly like the one big database you were escaping. Hash a high-cardinality id (customer_id, order_id) to spread rows evenly, and before committing, ask the paranoid question: "which single key value will be hottest, and does everything about it land on one shard?" One celebrity account, one viral link — that is how hotspots are born.
Quick check
A customer changes their delivery address (written to the primary) and the confirmation page instantly re-reads their profile FROM A REPLICA. What can go wrong?
Match them up
Match each term to its plain meaning.
0/5 matched — tap a term on the left.
Build it yourself
Rescue SliceNow's 900-reads/sec database. Writes go to the primary; reads go to the replica; the primary keeps the replica in sync. One palette piece splits data we have no reason to split yet — leave it off.
Apply it in an interview
The URL shortener's deep-dive asks how the design changes across three continents — replicas per region is the heart of a strong answer. Go make the argument.