Replication vs sharding

The decision

Replication keeps copies of the same data on more than one server. One leader takes the writes, and followers copy it and answer reads. Sharding splits the data over several servers, so each server holds only a part and takes only a part of the writes. Replication scales reads and gives a backup copy. Sharding scales writes and data size. They solve different limits, and big systems use both.

Choose replication when

• Reads are the problem: they are far more than writes.
• You need a second copy for safety or for a quick switch when the leader fails.
• All the data fits on one server, and one server can take all the writes.
• You want the simplest scale-out. Queries and transactions still work as before.

Choose sharding when

• Writes are above what one server can do, and a bigger server does not help or costs too much.
• The data is bigger than one server's disk.
• You have already used the cheaper steps: indexes, a cache, followers and a bigger server.
• Most queries carry one shard key, such as a user ID, the value that decides which shard holds a row. Then most queries touch one shard.

The numbers that change the answer

Case 1: reads are the limit. A food app's database. Assumptions: one server has 8 cores, which is 8,000 ms of work per second. We plan for 70%: 5,600 ms. At peak, 1,500 reads per second at 4 ms each, and 300 writes per second at 8 ms each. A follower spends 0.5 ms to apply a change.

• One server: 1,500 x 4 + 300 x 8 = 6,000 + 2,400 = 8,400 ms, which is 105% of the server. It fails.
• Two followers share the reads: each takes 750 x 4 + 300 x 0.5 = 3,150 ms, which is 39%.
• The leader has the writes only: 300 x 8 = 2,400 ms, about 30%. It also sends each change to the followers (0.25 ms each, assumed), so about 32%.

Replication fixed it with 3 servers. Now the limit on writes: 5,600 / 8 = 700 per second with no follower. With three followers, 5,600 / (8 + 3 x 0.25) = 640 per second. Followers do not raise the write limit.

Case 2: writes and data are the limit. Assumptions: 5,000 writes per second at 8 ms each. A server has 16 cores: 16,000 ms per second, and 70% is 11,200. The data is 9 TB. A 4 TB disk is filled to 70%, which is 2.8 TB.

• Writes: 5,000 x 8 = 40,000 ms, which is 250% of a server. Shards needed: 40,000 / 11,200 = 3.6, so 4.
• Data: 9 / 2.8 = 3.2, so 4.
• With 4 shards: each takes 10,000 ms (62.5%) and 2.25 TB.
• With a leader and 2 followers for each shard: 4 x 3 = 12 servers, against 3 before.

The price of changing shard count. With "hash mod N", going from N to N + 1 shards moves a share N / (N + 1). From 4 to 5: 4 / 5 = 80% of rows move, which is 0.8 x 9 TB = 7.2 TB. On one 1 Gbps link (125 MB per second): 7,200,000 / 125 = 57,600 seconds = 16 hours.

What breaks with each choice

• Replication: a follower can show old data, because copying takes time. In Postgres, copying is asynchronous by default, with a small delay, and changes not yet shipped are lost if the leader fails (see Sources). Every follower holds all the data. Followers add a little work to the leader. A follower is not a backup: a wrong delete is copied to it too, so keep real backups.
• Sharding: a query without the shard key must ask every shard and merge the answers (scatter-gather). A join or a transaction across shards is hard. IDs must be unique across shards. A bad key makes one hot shard. Changing the shard count moves data.

What it costs

• Replication adds servers in a simple way: 2 followers triple the servers (3 instead of 1).
• Sharding multiplies the servers (12 here). It adds routing code, a plan for resharding (moving data when the shard count changes), and extra work for every query and report.
• Moving later is easy in one direction only. Adding a follower takes hours to days (rough guess). Adding sharding to a running system takes months (rough guess), because every query must carry the key.
• So use replication and cheaper steps first, and shard when the numbers force you.

How each level answers

SDE-1: Replication copies the data. Sharding splits the data.

SDE-2: For a read-heavy app I add followers. For more writes than one server can do, or more data than one disk holds, I shard by a key like user ID.

Senior: At 1,500 reads and 300 writes per second, one server is at 105%, and two followers bring it to 39%. At 5,000 writes per second the work is 250% of a server, so I use 4 shards. The risk is queries without the key and a bad key. The fallback is to keep a directory table so I can move single keys.

Staff: I ask which limit is real, and what a wrong choice costs in engineers. I delay sharding as long as the cheaper steps work, because it multiplies cost and slows every team. I pick the key together with the product teams, and one team owns routing and resharding. I check the choice by load per server, the share of queries that touch one shard, and follower lag (how far followers are behind).

Say it in the interview

If reads are the limit I add followers. Two followers took my example from 105% to 39% load. If writes or data are the limit I shard by user ID, which gives 4 shards for 5,000 writes per second and 9 TB. Followers do not raise the write limit, and sharding costs queries without the key.

Common mistakes

• Adding followers to fix a write problem. All writes still go to the leader.
• Sharding too early. It multiplies servers (3 to 12) and complicates every query.
• Choosing a key that only grows, such as the date. All new writes hit one shard.
• Forgetting that hash mod N moves most rows when N changes.

Sources

• Postgres streaming replication (asynchronous by default; read-only standby; unshipped transactions can be lost): https://www.postgresql.org/docs/current/warm-standby.html (opens in a new tab) (checked 26 Oct 2026).
• All request rates, CPU costs, data sizes and disk sizes are assumptions made for teaching. The 1 Gbps = 125 MB per second figure is 1,000 megabits divided by 8.