Sharding

SYSTEM DESIGN SERIES  ·  TOPIC 14 OF 23+  ·  part of the 13 → 14 → 15 chain
1. One Shard vs All of Them
Same kind of query, very different amounts of work (looping)
Single-shard: the query carries a shard key - router computes exactly one destination
Single-shard: the other shards are never touched, never even asked
Single-shard: latency looks like querying one small database, because it is
Cross-shard: no single key - the query has to fan out to every shard
Cross-shard: the whole query waits for the single slowest shard to answer
Cross-shard: then the results still have to be merged before anyone gets an answer
2. Sharding vs Replication - Not the Same Thing
Copies of everything vs slices of everything
  • Replication (topic 11) - every replica holds the same full data
  • Sharding - every shard holds a different subset of the data
  • Replication scales reads and durability; sharding scales writes and storage
  • Most large systems do both - and each shard is itself replicated
📚 Analogy: Replication is photocopying the whole library into five buildings. Sharding is splitting the one library across five buildings, fiction here, reference there.
3. Partitioning Strategies
How you decide which shard a row belongs on
Range-Based
Split by key ranges (A–M, N–Z). Great for range queries - risks a hot shard if data or traffic isn't even.
Hash-Based
hash(key) mod N. Spreads load evenly - but breaks ranges, and adding a shard reshuffles almost everything.
Directory-Based
A lookup table maps key → shard. Flexible - but now the directory is a new thing that must never go down (topic 02).
4. The Hot Shard Problem
Even data volume doesn't mean even traffic
  • One key (a celebrity account, a viral post) can swamp its one shard
  • The other shards sit idle while this one is on fire
  • Fixes: split the hot key further, or cache in front of it (topic 07)
5. Cross-Shard Queries & Transactions
The part sharding makes genuinely harder
  • A join across shards means scatter-gather - slower, by construction
  • A transaction touching two shards can't use plain local ACID (topic 13) anymore
  • It needs real distributed coordination (two-phase commit) - or should be designed away
  • A good shard key keeps things that are queried together, together
6. Choosing a Good Shard Key
The single most consequential decision in sharding
Spreads Load Evenly
Colocates Related Data
Stable Over Time
Matches Real Query Patterns
Pick the shard key once - changing it later means moving everything
This decision outlives most others in the system. Get it wrong and every fix downstream is a workaround, not a solution.
7. When to Shard (and When Not To)
Shard when:
✔ One node's disk or write throughput is genuinely maxed
✔ Data volume keeps growing with no ceiling in sight
✔ Vertical scaling (topic 04) has run out of room
Sharding Buys Capacity by Spending Simplicity
Hold off when:
✔ Read replicas (topic 11) alone would fix it
✔ A bigger box (topic 04) is still cheaper than the complexity
✔ Nobody's asked "which shard is this on?" yet, in production
💡 Hash-based sharding breaks the moment you add or remove a shard. Fixing that resizing pain is Consistent Hashing - topic 15, next.