Sharding
- Pradeep P
- 3 days ago
- 4 min read
Layer 1 · Post 15 of 15
← Previous: Replication → Next: REST APIs
Layer 1 — The building blocks · Post 15 of 88
Sharding splits data across machines so no single database has to hold or serve everything. The hard part is choosing the split and living with it.
What you'll learn
How sharding differs from replication
What a shard key is, and how a bad one creates a hot shard
Why you postpone sharding until you have to
The idea in one minute
Replication copies the same data to more machines.
Sharding (partitioning) puts different data on different machines.
Users A–M → Shard 1 (its own primary + replicas)
Users N–Z → Shard 2
Each shard is a smaller database. Together they hold the whole set. No single box has to store or write everything.
The price: you must know which shard to talk to. Cross-shard joins and transactions become painful. Moving data later is a project.
Why it matters
Vertical scaling of the primary has a ceiling. Replicas help reads. When writes, storage, or connections no longer fit, you split the data.
Sharding is also how many NoSQL systems scale writes from day one: the partition key is the shard key. In SQL land, you often wait — because a single Postgres with replicas is simpler for years.
Interviewers like sharding because it shows you understand data gravity. Drawing 50 app servers without a story for the data is incomplete. Drawing 50 shards without a key is worse.
How it works
The shard key
Every row (or document) is assigned to a shard by a key.
Strategy: By user id; Example: shard = hash(user_id) % N; Risk: Great if queries are per user. Cross-user reports need a warehouse.
Strategy: By tenant; Example: Each customer on a shard; Risk: One huge tenant is a hot shard.
Strategy: By time; Example: New months on new shards; Risk: Old shards idle; "last 5 minutes" all hit one shard.
Strategy: Geographic; Example: EU vs US; Risk: Legal win; "global user" is messy.
Hash sharding spreads load evenly if keys are even. Range sharding (A–M, N–Z) is easy to reason about and easy to skew (S has more surnames than X).
Finding the shard
The app (or a proxy like Vitess, Citus, a custom router) computes the shard from the key, then opens a connection to that database.
If the request does not include the key — "find user by email" when you sharded by user_id — you must scatter to all shards or keep a lookup table. Scatter-gather is slow and gets slower with every shard you add.
What gets hard
Joins across shards: usually in the app, or not at all.
Transactions across shards: not a single BEGIN; see sagas and 2PC in Layer 4.
Resharding: hash % 4 to hash % 8 means moving half the data. Consistent hashing and range splits exist to make this less awful, not free.
Secondary indexes: a global "email unique" index is a new distributed problem.
Sharding vs partitioning (wording)
In Postgres, table partitioning can split a table by range on one machine (or with FDW). Sharding usually means separate servers. Same idea, different blast radius.
A simple example
A social app stores 2 billion follows rows. One primary cannot take the write QPS.
You shard by follower_id. "Who do I follow?" hits one shard. "Who follows celebrity X?" is the inverse graph — that query fans out or you store a second copy sharded by followee_id (denormalize, double writes). Teams do this. It is the join you gave up.
A new celebrity signs up and is sharded onto shard 7. If you sharded by followee_id only, shard 7 melts. Hashing user ids usually avoids "letter S" skew, but hot keys still exist — one id with 80 million followers. That key needs a special case (separate cluster, cache, write fan-out). Sharding did not erase popularity.
Common mistakes
Sharding at 10,000 users because a blog said so. You bought distributed transactions before product-market fit.
A shard key that is not in your queries. You built a random number generator that requires scanning the fleet.
Assuming N shards = N× write capacity with a hot partition. Capacity is per shard, and one shard can still be 90% of traffic.
Unique constraints globally ("this username is unique") without a global index or an allocation service. Two shards will both accept "ada".
Forgetting operational cost. N shards means N backups, N failovers, N schema migrations. Tooling (Vitess, Spanner, DynamoDB) exists because this hurt.
How this shows up in real systems
Instagram / early Facebook: sharded MySQL by user.
DynamoDB, Cassandra, Cosmos DB: sharding is the default; you design the partition key or you suffer.
Citus, Vitess, Cockroach, Spanner: SQL-shaped systems that shard for you with restrictions.
When you propose sharding in an interview, state the key, a hot-key plan, and which queries cannot be single-shard.
Recap
Sharding splits data across machines; replication copies it.
The shard key is the design. It must match how you look data up.
Postpone it until a single primary (plus replicas) is actually the wall — then split on purpose.
You now have the Layer 1 toolbox: machines, front doors, caches, and data that copies or splits. Layer 2 is how those pieces talk.
Layer 1 · Post 15 of 15
← Previous: Replication → Next: REST APIs
Comments