Chapter 08 — Sharding & Partitioning

Shreyesh kolhe
July 10, 2026

Chapter 08 — Sharding & Partitioning

Hey everyone! Welcome back to Namaste System Design! 🙏

Replication (Chapter 07) copies the whole database — great for reads, but every copy still holds all the data and takes all the writes. When you have 500 million users and 50 terabytes of data, no single machine can hold it. The answer is to split the data across machines. That's sharding, and it's the deepest end of the data pool.

What we will cover:

  • Partitioning vs sharding (the pizza analogy)
  • How sharding scales writes AND storage
  • Sharding strategies: range, hash, directory
  • The dreaded "hotspot" problem
  • Why cross-shard queries hurt
  • Resharding & a teaser for consistent hashing
  • Interview Questions

1. The Pizza Analogy

One giant pizza, ten hungry friends. You can't clone the pizza (that's replication — same toppings everywhere). Instead you slice it, and each person holds a different slice. 🍕

┌─────────────────────────────────────────────────────────────┐
│   SHARDING = splitting ONE database into pieces (shards),   │
│   where each shard holds a DIFFERENT subset of the data.    │
│                                                             │
│   Replication  → same data copied many times (Ch 07)        │
│   Sharding     → different data split across machines       │
└─────────────────────────────────────────────────────────────┘

BEFORE (one huge DB):        AFTER (3 shards):
┌───────────────────┐        ┌─────────┐ ┌─────────┐ ┌─────────┐
│ users 1–3,000,000 │   ──▶  │ users   │ │ users   │ │ users   │
│    (50 TB) 🥵     │        │ 1–1M    │ │ 1M–2M   │ │ 2M–3M   │
└───────────────────┘        └─────────┘ └─────────┘ └─────────┘
   won't fit / too slow        each holds ~17TB, fast 😌

(Note: "partitioning" is the general term for splitting; "sharding" usually means partitioning across separate machines. Interviews use them interchangeably.)

2. Why Shard? What It Uniquely Solves

✅ WRITE SCALING   → each shard takes only its slice of writes.
                    (Replication couldn't do this — one leader.)
✅ STORAGE SCALING → data too big for one disk now spreads out.
✅ SMALLER INDEXES → each shard's index is smaller → faster queries.

⚠️ COST: complexity explodes. Sharding is a LAST resort, only
   when replication + caching are no longer enough.

3. How Do We Decide Which Shard? (The Shard Key)

You pick a shard key (e.g. user_id) and a strategy to map it to a shard.

StrategyHow it worksDownside
Range-basedusers A–H → shard 1, I–P → shard 2...Uneven! Lots of names start with 'S' → hotspot
Hash-basedhash(user_id) % N → shard numberEven spread, but resharding is painful
Directory-basedA lookup table says which shard holds each keyFlexible, but the lookup table is a new bottleneck
HASH-BASED (most common):
   shard = hash(user_id) % 3

   user 1001 → hash → 7  → 7 % 3 = 1 → Shard 1
   user 1002 → hash → 9  → 9 % 3 = 0 → Shard 0
   user 1003 → hash → 8  → 8 % 3 = 2 → Shard 2

   Nicely spread out. But watch what happens if N changes...

4. The Hotspot Problem

The nightmare of sharding: one shard gets way more traffic than the others, defeating the whole purpose.

   Shard by COUNTRY:
   ┌──────────┐ ┌──────────┐ ┌──────────┐
   │  India   │ │  Bhutan  │ │  Nauru   │
   │ 400M 🔥🔥 │ │  50k     │ │   30     │
   └──────────┘ └──────────┘ └──────────┘
      overloaded    idle         idle

   Bad shard key → uneven load → one shard melts while
   others nap. Choose a HIGH-CARDINALITY, evenly-distributed
   key (like a hashed user_id), not "country".

Same issue with a celebrity: if you shard tweets by author, Cristiano Ronaldo's shard gets hammered. Real systems special-case such "hot" keys.

5. The Pain: Cross-Shard Queries

Once data is split, operations that need many shards get expensive.

   "Get user 1042's profile"  → one shard → fast ✅

   "Count ALL users who joined today"  → must ask EVERY
   shard and merge results → slow, complex (a scatter-gather) ❌

   JOINs across shards? Even worse — often you can't, so you
   DENORMALIZE (duplicate data) to keep queries on one shard.

Design lesson: choose your shard key so that your most common query hits a single shard. This is the whole game.

6. Resharding & Consistent Hashing (Teaser)

With hash(key) % N, adding a shard changes N — so almost every key now maps to a different shard, forcing a massive, painful data migration.

   Was:  hash % 3    Now:  hash % 4
   → nearly EVERY key moves to a new shard. Migration hell. 😭

Consistent hashing solves this elegantly — adding a shard moves only a small fraction of keys, not all of them. It's so important it gets its own Deep Dive 01.

Interview Questions — Quick Fire!

Q: What is sharding and how is it different from replication?

"Sharding splits a database into pieces called shards, where each shard holds a different subset of the data across separate machines. Replication keeps full copies of the same data. Replication scales reads and improves availability, but every copy still holds all the data and takes all the writes. Sharding is what scales writes and total storage, because each shard handles only its slice."

Q: What are common sharding strategies?

"Range-based splits by key ranges, which is simple but risks uneven distribution. Hash-based applies a hash function to the shard key to spread data evenly, but makes adding shards harder. Directory-based uses a lookup table mapping keys to shards, which is flexible but adds a lookup layer that can become a bottleneck. Hash-based is the most common."

Q: What is a hotspot in sharding and how do you avoid it?

"A hotspot is when one shard receives disproportionately more traffic or data than others, so it becomes overloaded while others sit idle — which defeats the point of sharding. It usually comes from a poorly chosen shard key, like sharding by country. You avoid it by choosing a high-cardinality, evenly distributed key such as a hashed user ID, and special-casing known hot keys like celebrity accounts."

Q: Why are cross-shard queries a problem?

"Because a query that needs data from many shards has to fan out to all of them and merge the results — a scatter-gather that's slow and complex — and joins across shards are often impractical. The mitigation is to pick a shard key so the most common queries hit a single shard, and to denormalize data when needed so related data lives together."

Key Points to Remember

ConceptKey Takeaway
ShardingSplit data across machines; each shard holds a different subset.
Uniquely solvesScales WRITES and STORAGE (replication can't). A last resort — high complexity.
Shard keyPick high-cardinality, evenly distributed. Make common queries hit one shard.
HotspotsBad keys overload one shard. Avoid "country"; watch for celebrity keys.
Reshardinghash % N makes adding shards painful → consistent hashing (Deep Dive 01).

What's Next?

We've been dancing around a fundamental tension: when data is spread across machines, can it be both perfectly consistent AND always available? Chapter 09 confronts the most famous theorem in distributed systems — the CAP theorem.

Keep designing, keep scaling! See you in the next one!