Imagine your town has one tiny library with one librarian and one copy of every book.
At first, it works fine. But then the whole town gets excited about reading. Hundreds of kids line up at the single desk. And one day, a pipe bursts and soaks the only copy of Harry Potter. Now nobody can read it.
The town council has two ideas:
- Make photocopies of the whole library and open copy-libraries in other neighborhoods, so more kids can read at the same time and nothing is lost if one building floods. This is Replication.
- Split the books across buildings: authors A–M in the North Library, N–Z in the South Library, so no single building has to hold everything. This is Sharding.
In Episode 9 we picked a database. In this episode, we learn how to keep that database alive when millions of people use it.
Keywords
- Replication: Keeping identical copies of the same data on multiple database servers.
- Leader (Primary): The one replica that accepts writes.
- Follower (Replica / Secondary): Copies that receive changes from the leader and serve reads.
- Replication Lag: The small delay before a follower catches up with the leader.
- Failover: Promoting a follower to leader when the leader dies.
- Sharding (Horizontal Partitioning): Splitting rows of data across multiple databases, each holding only a slice.
- Shard Key: The field used to decide which shard a row belongs to (e.g.,
user_id). - Hot Shard: One shard getting far more traffic than the others.
Character Mapping
- Leader Database: The Head Library, the only place where new books get added.
- Follower Replicas: Photocopy branch libraries that get new books delivered from the Head Library.
- Shards: Separate library buildings, each owning a range of authors.
- Shard Key: The first letter of the author's last name.
- Router / Proxy: The signpost at the town square telling you which building has your book.
Part 1: Replication (Making Photocopies)
How Leader-Follower Replication Works
Step 1: All Writes Go to the Leader When you post a photo or update your profile, that write goes to the Leader database only.
Step 2: The Leader Ships Changes to Followers The leader keeps a log of every change ("row 42 updated"). Followers read this log and apply the same changes to their own copy.
Step 3: Reads Spread Across Followers Most apps read far more than they write. Instagram users scroll (read) hundreds of posts for every one they upload (write). Sending reads to followers spreads the load across many machines.
Step 4: Failover When Disaster Strikes If the Leader crashes, one follower is promoted to become the new Leader, and the app keeps running.
The Catch: Replication Lag ⏳
Copies take a moment to arrive. If you change your profile name and the next page load reads from a follower that hasn't caught up yet, you might see your old name for a second.
Common fix: "Read your own writes": for a few seconds after you update something, your reads go to the Leader.
Sync vs Async Replication
| Synchronous | Asynchronous | |
|---|---|---|
| How it works | Leader waits for followers to confirm before saying "saved" | Leader says "saved" immediately, followers catch up later |
| Speed | Slower writes | Fast writes |
| Data safety | No data lost if leader dies | Last few changes might be lost |
| Used for | Banking, payments | Social feeds, likes, view counts |
Part 2: Sharding (Splitting the Library)
Replication helps with reads, but every follower still holds all the data, and every write still goes through one leader. When you have 3 billion users, that single leader becomes the bottleneck.
Sharding solves this by splitting the data itself.
How Sharding Works
Step 1: Choose a Shard Key
For a social app, user_id is a common choice.
Step 2: Map Keys to Shards
- Users 1–1,000,000 → Shard A
- Users 1,000,001–2,000,000 → Shard B
- Users 2,000,001–3,000,000 → Shard C
Or, more commonly, use a hash: shard = hash(user_id) % number_of_shards.
Step 3: Route Every Query When user 1,500,321 opens the app, the router knows their data lives on Shard B and sends the query straight there.
Three Sharding Strategies
- Range-Based: Split by ranges (A–M, N–Z or dates). Simple, but new data often piles onto the last shard.
- Hash-Based: Run the key through a hash function. Spreads data evenly, but range queries ("all orders this week") get harder.
- Geo/Directory-Based: Bangladesh users on the Singapore shard, European users on the Frankfurt shard. Keeps data close to users and helps with local laws.
The Dangers of Sharding ⚠️
- Hot Shards: If a celebrity with 200 million followers lives on Shard C, Shard C melts while A and B are bored. Choose keys that spread traffic evenly.
- Cross-Shard Queries: "Find the top 10 posts across all users" now has to ask every shard and merge the results. Slow and expensive.
- Resharding Pain: Going from 3 to 4 shards with
hash % Nmoves almost every row. We'll fix this exact problem in Episode 13: Consistent Hashing. - No Easy Joins: Joining two tables that live on different shards is hard. Keep related data on the same shard.
Part 3: Using Both Together
Real systems combine both techniques: shard the data, then replicate each shard.
Each shard has its own leader and followers. Sharding gives you write capacity. Replication gives you read capacity and safety.
Real-World Applications
- Instagram: Shards PostgreSQL by user ID across thousands of logical shards, each with replicas.
- Daraz / Amazon: Product catalog reads are served from many read replicas, so a flash sale's browsing traffic never touches the write leader.
- Discord: Stores trillions of messages sharded by channel ID, so all messages in one chat live together.
- Uber / Pathao: Trip data is sharded by city or region, keeping Dhaka's rides separate from Chattogram's.
Replication vs Sharding at a Glance
| 📄 Replication | ✂️ Sharding | |
|---|---|---|
| What it copies/splits | Copies all data to many servers | Splits data so each server has some |
| Main benefit | More read capacity + high availability | More write capacity + more total storage |
| Biggest risk | Replication lag (stale reads) | Hot shards, cross-shard queries |
| Complexity | Low–Medium | High |
| Do it when | Reads are slowing down | One machine can't hold or write all the data |
🍕 Explain It Like You're 5
You have a giant coloring book that everyone in class wants to color.
Replication: The teacher makes photocopies so five kids can color the same pictures at once. If someone spills juice on one copy, there are still four left.
Sharding: The teacher tears the book in half. Pages 1–50 go to Table A, pages 51–100 go to Table B. Each table has less to carry, and both tables can work at the same time.
🎯 The System Design Interview Summary
Interviewers love asking, "Your database is getting slow. What do you do?" Walk through it in order:
- Add indexes and a cache first (see Episode 7: Redis). Cheapest fix.
- Add read replicas if reads are the bottleneck.
- Scale vertically (bigger machine) while it's still affordable.
- Shard only when writes or data size outgrow one leader.
Key Takeaways for Senior Interviews:
- Pick the shard key carefully: It should spread load evenly and keep data that's queried together on the same shard.
- Mention replication lag: And how you handle "read your own writes."
- Plan for failover: Automatic leader election (e.g., via Raft-based tools) avoids downtime.
- Know the cost: Sharding makes joins, transactions, and schema changes much harder. Don't do it before you need it.
Next up: how do we stop one greedy user or bot from overwhelming all this hard work? Rate Limiting.