What it's for
- Full-copy single-leader replication — the setup from the previous chapter — is great for reads, but every replica still takes every write and holds every row. Sharding is the exit for writes and storage: split the data by key so no machine holds all of it.
- Each shard owns a slice of the key space, so writes and keyed reads both spread — at the price of everything that crosses slice boundaries.
Good to know
The router shown is hash(key) mod 3 — horizontal partitioning: different rows per shard, not different columns (vertical partitioning, not shown) and not copies (replication, the previous chapter). The mapping is deterministic, so every request for a key finds its shard, and uniform, so even keys spread evenly in this toy. Real systems prefer consistent hashing precisely because adding a shard then moves few keys instead of most — that trade is the next chapter. The costs hide at the boundaries: a question without the key asks every shard and merges (scatter-gather — as slow as the slowest shard, plus the merge), transactions that span shards need coordination, and joins stop being local — each has specific mechanisms and costs, none free, none impossible. Even rows are not even load: a hot key defeats the whole split, because one celebrity's rows live in exactly one shard and no number of extra shards helps; the usual answers (split the hot key, cache it) are workarounds, not math. Resharding is a migration, not a config change: keys move between machines while traffic keeps arriving, routing metadata must switch honestly, and with mod-N hashing going from 3 shards to 4 remaps most keys. And every shard still wants its own replicas for reads and failover — sharding and replication compose, they don't replace each other.
How it works, step by step
Why the steps go in this order
- The limit comes first: one database, full and busy, with writes it can't shed.
- Replication's failure is the motivation — if copies can't help, the data itself must move.
- The key rule appears before any traffic, because everything after it is just following the rule.
- Writes route before reads: the slice that accepts a key's writes defines where its reads must go.
- The hot key and resharding come last: splitting evenly is easy; real data is never even.
Before you rely on it
This is a toy: three shards, colored keys, a hand-set hash split and a hand-set hot key. Real shard counts, key distributions and hotspots look nothing like the tray — "each shard holds a third" is this toy's arithmetic, not a property of hashing, and sharding guarantees no linear scaling, no lower latency and no extra availability: losing an unreplicated shard loses access to its slice (a third of the rows here) until it's restored. Whether to shard at all comes last in a real design: caches, replicas and a bigger machine come first, and the cited sources describe production systems with their own measured behavior.