Scaling data: replication and sharding
Stateless servers are easy to multiply; data is not. Learn how read replicas spread read load, what replication lag does to users, and how sharding splits data across machines — with a live comparison of modulo hashing and consistent hashing.
In this lecture you will
- Explain leader–follower replication and when read replicas help
- Recognize replication lag and design around read-your-writes problems
- Explain sharding and how to choose a shard key
- Compare modulo hashing and consistent hashing when servers are added or removed
The previous lectures multiplied stateless servers and cached reads. Eventually, the database becomes the bottleneck: too many reads, too many writes, or simply too much data for one machine. Scaling data is harder than scaling servers, because data has to stay correct while it is copied and split. There are two fundamental techniques: replication and sharding.
Replication: copies of the same data
In leader–follower replication, one node — the leader — accepts all writes and streams every change to one or more followers (replicas). Replication gives you:
- Read scaling — send read-only queries to replicas;
- High availability — if the leader fails, promote a replica;
- Geographic reach — place replicas near users in other regions.
It does not scale writes: every write still goes through the one leader.
- Synchronous replication
- The leader waits for a replica to confirm each write. No committed data is lost if the leader dies, but writes get slower.
- Asynchronous replication
- The leader doesn’t wait. Writes stay fast, but replicas lag slightly behind, and the most recent writes can be lost in a failover.
- Replication lag
- How far a replica trails the leader — usually milliseconds, sometimes seconds under load.
Lag creates a classic bug: a user saves a change, the next page is served from a replica that hasn’t received it yet, and the change seems to have vanished. The usual fix is read-your-writes: for a short time after a user writes, serve that user’s reads from the leader.
- Leader and replicaThe leader takes every write and streams changes to a replica asynchronously. Reads are spread across replicas to take load off the leader.
- A writeAsha changes her display name. The leader commits it at once and starts shipping the change to the replica.
- A stale readHer next page load happens to read from the replica, which hasn’t applied the change yet. Her new name seems to have vanished — and she saves it again, or files a bug.
- Catching upA moment later the replica applies the change. Nothing was lost; the read simply came too early.
- Read your writesThe fix: for a few seconds after a user writes, route that user’s reads to the leader — or to a replica known to have caught up with their write. Everyone else keeps reading from replicas.
The lag is exaggerated so you can see it; usually it is milliseconds, but it grows under heavy load.
Sharding: splitting the data
When writes or total data size outgrow a single leader, you shard (partition): split the data so each shard — a separate database with its own replicas — holds only part of it. Each row belongs to exactly one shard, chosen by a shard key:
- By range — customers A–F on shard 1, G–M on shard 2… Easy range queries, but prone to hot spots.
- By hash — hash the key to pick a shard. Spreads load evenly, but range queries touch every shard.
- By entity — all data for one tenant or customer together, so most queries hit one shard.
Choose the key that keeps the most common queries on a single shard and spreads load evenly. A bad shard key — say, a date, where all of today’s writes land on one shard — creates a hot spot, and changing the key later means moving all the data. Try three candidate keys for an orders table:
A simulation of today’s 2,000 orders from 10,000 customers, spread over four shards. It is seeded, so every reader sees the same numbers.
Moving data when servers change
How keys map to servers matters most when the number of servers changes — scaling up, or replacing a failed node. Compare the two strategies:
36 keys placed by the same hash function. Keys that moved after the last change are outlined.
With hash mod N, adding one server changes N, so most keys land somewhere new. For a cache, that means most entries become misses at once; for a database, a huge migration. Consistent hashing places servers and keys on a ring, and each key belongs to the next server clockwise. Adding a server takes over only the keys between it and its neighbour — on average 1/N of them. Virtual nodes — several ring positions per server — even out the load.
Consistent hashing, or variations of it, underpins many distributed caches and databases — Apache Cassandra, for example, and the original Amazon Dynamo design.
Replication and sharding scale where data lives. The final lecture of this module decouples when work happens — with queues.
Key takeaways
- Replication copies data to several machines for read scaling and failover; writes still go to one leader.
- Asynchronous replicas can lag behind, so a user may not immediately see their own write.
- Sharding splits data so each machine holds and serves only part of it; the shard key decides everything.
- Consistent hashing moves only a small fraction of keys when the number of servers changes; modulo hashing moves most of them.
Check your understanding
3 questions · answers explainedQ1Your database is overloaded by reads, while writes are modest. What is usually the simplest first step?
Q2A user updates their profile, then immediately reloads and sees the old version. What is the likely cause?
Q3A cache cluster uses server = hash(key) mod N. What happens when you add one server?