Sharding
Replication made copies of your data so you'd never lose it. But copies don't help with a different problem: what if the data is simply TOO BIG to fit on one machine at all? You can't copy your way out of that — every copy would need to be just as huge. The answer is to split the data into pieces and put each piece on its own machine. Each piece is called a shard. The whole game is choosing how to cut it.
Sharding = splitting your data across many machines
Imagine a phone book so heavy no single shelf can hold it. The obvious fix: tear it into volumes — A–H on one shelf, I–Q on the next, R–Z on a third. Now each shelf holds a chunk it can actually carry, and together the volumes still cover everyone. Sharding does this to a database. You take one giant dataset and split it into chunks called shards, each living on its own machine. Maybe users with names A–M go to shard 1 and N–Z go to shard 2. No single machine holds everything anymore — and that's the point, because no single machine COULD.
The shard key: how you decide where each piece goes
When a new user signs up, which shard do they go on? You need a rule. The piece of information you use to decide is called the shard key. If you shard by the first letter of the name, then the name is your shard key: 'Maya' starts with M, so M lives on shard 1. Why does the key matter so much? Because it decides how evenly the data — and the work — gets spread. Picture sharding by the first letter and discovering that a third of your users have names starting with A through C. Now one shard is stuffed full and overloaded while the others sit nearly empty. That overloaded shard is called a hot shard, and it can drag the whole system down. A good shard key spreads things evenly so no single shard gets buried.
Sharding is NOT replication — don't mix them up
This is the trap almost every beginner falls into, so slow down here. Replication and sharding both involve 'lots of machines holding data,' but they do OPPOSITE things. Replication = the SAME data copied onto many machines. Every machine has the whole thing. Goal: don't lose data, and serve more readers. Lose a machine and you've lost nothing — another copy has it. Sharding = DIFFERENT data split across many machines. Each machine has only its slice, and no machine has the whole thing. Goal: fit data that's too big for one machine. Lose a shard with no backup, and you've lost that slice of the data. The one-line test: are the machines holding the same data or different data? Same → replication. Different → sharding. (And here's the kicker: real systems do BOTH — they shard the data into slices, then replicate each slice so losing a shard's machine doesn't lose that slice.)
The price of sharding: some questions now span many machines
When all your data lived on one machine, asking 'list every user who signed up today' was easy — one machine, one answer. After sharding, those users are scattered across every shard. Now you have to ask all the shards and stitch their answers together. Questions that touch many shards get slower and more complicated. It gets trickier if a question needs data from two shards at once — say, a money transfer between two users who happen to live on different shards. Coordinating a change across machines is genuinely hard. So sharding isn't free: you unlock storing enormous data, but you pay with harder cross-shard questions. That's why you only shard once one machine truly can't cope — not before.
It's a tradeoff
| Option | 👍 Pro | 👎 Con |
|---|---|---|
| Shard by range (e.g. users A–H, I–Q, R–Z) | Simple to reason about, and 'nearby' data sits together — great for questions like 'everyone from A to C'. | Easily lopsided: if one range is far more popular (lots of A names, or newest signups), that shard becomes a hot, overloaded spot. |
| Shard by hash of the key (scramble it, then split) | Spreads data very evenly — almost no hot shards, because scrambling mixes everyone up across the shards. | Loses the 'nearby data together' nicety, so range questions ('everyone A–C') must hit every shard and gather the results. |
Questions you might have
▸What's the difference between sharding and replication? They sound the same.
They're opposites. Replication puts the SAME data on many machines (copies — for safety and more readers). Sharding puts DIFFERENT data on many machines (slices — so huge data fits). The quick test: are the machines holding identical data or different pieces? Identical = replication. Different pieces = sharding.
▸What is a shard key and why does picking it matter so much?
The shard key is the piece of info you use to decide which shard a record belongs to — like 'first letter of the name'. It matters because it controls how evenly data is spread. A bad key piles too much onto one shard (a 'hot shard') while others sit idle, and that overloaded shard slows everything down.
▸What's a 'hot shard'?
A shard that ends up with far more data or far more traffic than the others, because the shard key didn't spread things evenly. It's the overloaded one straining while its neighbors are bored. Hot shards are the classic sign of a poorly chosen shard key — the whole reason key choice is the hard part of sharding.
▸If a shard's machine dies, do I lose that data?
If that shard had no copy, yes — you'd lose that slice, because no other machine holds it. That's exactly why real systems combine the two ideas: they shard the data into slices AND replicate each slice. So each shard is itself backed by copies, and losing one machine loses nothing.
▸Can't I just keep buying a bigger machine instead of sharding?
Only up to a point. A single machine has a ceiling — eventually there's no bigger one to buy, and the data outgrows any single box. Sharding has almost no ceiling: out of room? add another shard. That's why truly huge systems shard, even though it makes their questions harder to answer.
Best read after: Replication