← System Design · Lesson 5 of 11
Replication and Sharding
Copy the data to survive failure and scale reads; split it to scale writes.
The idea
These two get discussed together and solve different problems. Conflating them is one of the clearer signals in a system design interview.
Replication copies the same data to several machines. It buys durability — losing one machine does not lose the data — and it scales reads, because any replica can serve them. It does not scale writes at all: with a single primary, every write still goes through one machine.
The cost is lag. Asynchronous replication acknowledges the write before the replica has it, which means a user can write and then immediately read a stale value from a replica. This is not a rare edge case; it is the default behaviour, and "read your own writes" is the pattern that exists to work around it.
Sharding splits different data across machines. Shard 1 holds users A–M, shard 2 holds N–Z. This is what scales writes, because each shard has its own primary. It is also where most of the difficulty lives.
The shard key decides everything. A good key spreads load evenly and keeps most queries on one shard. A bad key produces a hot shard doing all the work while the rest idle — sharding by timestamp is the classic example, because all of today's writes land in one place. And a key chosen wrongly is extremely expensive to change once there is data.
What sharding takes away is worth stating plainly: joins across shards, and transactions across shards. Both become application problems. Queries that cannot be answered from one shard become scatter-gathers, which are as slow as the slowest shard and get slower as you add shards.
The order to reach for them: replicate first — it is simpler and solves durability, which you need regardless. Shard only when a single primary genuinely cannot absorb the write volume.
Walkthrough
When to reach for it
- Replicate for durability and failover — which is not optional for anything that matters.
- Replicate to scale reads, which is the cheapest large win available.
- Shard when one primary cannot absorb the write throughput, and not before.
- Shard when the dataset no longer fits on one machine, which is the other honest reason.
Rather than the obvious alternative
Caching
Cheaper and simpler for read load, with no durability benefit. Reach for a cache first; add replicas when you need fresh reads or failover as well.
Vertical scaling the primary
A bigger write machine defers sharding for a long time and costs a fraction of the complexity. Sharding is close to irreversible; resizing is an afternoon.
Functional partitioning
Splitting by table or service — orders here, analytics there — gets much of the benefit without a shard key. Try it before splitting a single table across machines.
Key terms
- Sharding
- Splitting data across machines by a partition key.
- Replication
- Copying data to additional nodes.
How to spot it
- The write rate is stated as beyond what one machine handles.
- The dataset is described in terabytes.
- The question asks what happens when the database machine dies.
- A user complains they cannot see something they just posted — that is replication lag.
Where it goes wrong
Assuming replicas are current
Reading your own write from a replica returns the old value. Route reads that must be fresh to the primary, or pin a user to the primary briefly after they write.
A shard key that creates a hot shard
Timestamps and auto-increment ids put every new write on one shard. Hash, or pick a key with natural spread.
Sharding too early
It is one of the hardest things to undo, and it makes every subsequent feature harder. Exhaust replicas, caching and a bigger primary first.
Forgetting cross-shard queries exist
Every query that does not include the shard key becomes a fan-out to all of them. Design the key around the queries, not around the data.