Core Concepts

What is Sharding (Partitioning)?

Watch: "Sharding in System Design Interviews w/ Meta Staff Engineer" — Hello Interview

Sharding (horizontal partitioning) splits one large dataset across several databases, called shards, so that each holds only part of the data. User 1–1M live on shard A, users 1M–2M on shard B, and so on. Each shard handles only its slice of reads and writes, so total capacity grows with the number of shards.

In simple words

A library too big for one building splits its books across branches: A–F in one, G–M in the next. Each branch serves only its share of readers. It works well until someone asks for "all books published in 2020", which means visiting every branch.

Each shard holds a slice of the data, so writes and storage scale with the number of shards.

Why It Exists

Caches and read replicas scale reads, but every write still lands on one primary, and the whole dataset must fit on it. When write throughput or data size outgrows the biggest practical machine, the only way forward is to divide the data.

How It Works

             shard key = user_id
app --> router --+-- hash(user_id) % 4 == 0 --> shard 0 (+ replicas)
                 +-- ... == 1 ---------------> shard 1
                 +-- ... == 2 ---------------> shard 2
                 +-- ... == 3 ---------------> shard 3

Strategies
  range:  user_id 1-1M -> A, 1M-2M -> B      range scans easy; hot ranges likely
  hash:   hash(key) mod N / consistent hash  even spread; range queries scatter
  directory: a lookup table key -> shard     flexible moves; the table is a dependency
  geo:    EU users -> EU shard               data residency, latency

Choosing the Shard Key

The shard key is the most important decision. A good key: (1) has high cardinality, (2) spreads load evenly, and (3) matches how data is queried so most requests touch one shard. For a chat app, conversation_id keeps each conversation's messages together. For a multi-tenant SaaS, tenant_id keeps each customer on one shard (with care for very large tenants).

What Gets Hard

Cross-shard queries: "top 10 posts across all users" must scatter to every shard and gather.
Cross-shard transactions: need two-phase commit or sagas; most designs avoid them by choosing a key that keeps related data together.
Hot shards: a celebrity or a big tenant overloads one shard.
Resharding: adding shards moves data. With hash % N, changing N moves almost everything; consistent hashing or many small virtual shards mapped to few machines moves only a fraction.
Unique IDs and joins no longer come for free from one database.

Key Pointers

Sharding scales writes and storage; replication scales reads and availability. Use both.
Pick the shard key from the dominant access pattern; aim for single-shard queries.
Plan for resharding from day one (virtual shards / consistent hashing).
Delay sharding until needed: it permanently complicates queries, transactions and operations.

Follow-up Questions

Why not shard by created_at (timestamp)?: All new writes land on the newest range, one hot shard, while old shards sit idle. Time works for archival partitioning, not for spreading write load.
How do you find which shard holds a key?: Compute it (hash of the key with consistent hashing) in a client library or router, or look it up in a directory service. Many systems cache the shard map in the router and refresh it on changes.
Sharding vs partitioning?: Often used interchangeably. "Partitioning" can also mean splitting a table inside one database (e.g. Postgres declarative partitions by month); "sharding" usually means partitions on separate machines.