Replication vs Sharding

Two different tools solving different bottlenecks. Replication copies data to scale reads and availability; sharding splits data to scale writes and storage. See where the bottleneck moves — and why large systems combine both.

Goal: Feel replication and sharding as two competing tools first — copy data vs split data — before combining them.Try: Pick a workload, then switch between Single, Replication, Sharding, and Combined while pushing read, write, and storage traffic up.

Step 01 · Concept snapshot

Copy data or split data?

Two different tools solving different bottlenecks.

Replication

DB
Replica
Replica
Replica

“Copy the same thing many times.”

Same data copied — store multiple copies.

Sharding

Shard A
Shard B
Shard C

“Split the work.”

Data divided — store different pieces.

Pick a workload

What changed

Read-heavy — timelines and profiles are read far more than written.

Why it matters

Replication spreads those reads across copies.

Step 03 · Main interaction

Same problem, four strategies

Switch the strategy and stress it. Watch where the bottleneck moves.

Step 02 · Stress the database

Change traffic, watch bottlenecks move

Every control updates the architecture, metrics, and insight together.

Node health

Consistency

Live architecture

Everything in one place.

reads writes
Users
Appserves requests
Databaseall data
Read scalability
45Tradeoff

One database serves every read.

Write scalability
68Tradeoff

One database serves every write.

Storage capacity
57Tradeoff

Limited to a single machine.

Availability
60Tradeoff

Single point of failure.

Step 05–09 · Cause and effect

What just happened?

What changed

All reads, writes, and storage converge on one database.

Why it matters

It works until any one of reads, writes, or storage exceeds a single machine.

Where's the bottleneck

The single database — every request and every byte lands here.

Step 10 · Challenges

Pick the right tool

Select a mode above. A card turns green when the current mode is the right answer.

Read traffic exploded

Replication

Writes overloaded the database

Sharding

Storage reached its limit

Sharding

Need better availability

Replication

Petabytes + very high reads

Both

Step 1: Start with a single database.
Step 2: Reads increase → add replicas to spread reads.
Step 3: Writes increase → add shards to split writes.
Step 4: Availability required → replicate each shard.
Step 5: Observe the new complexity: cross-shard coordination.

Summary

  • Replication copies the same data — it scales reads and adds availability, but writes still hit the primary.
  • Sharding splits the data — it scales writes and storage, but a lost shard takes part of the data with it.
  • Replication does not scale writes; sharding does not improve reliability on its own.
  • Large systems shard for scale, then replicate each shard for reliability — at the cost of coordination.
SQL vs NoSQLMessage Queues

Why this exists

Replication copies data to improve availability and read scale. Sharding splits data across nodes to increase total write throughput and storage capacity. Replication preserves the same dataset in more places. Sharding divides the dataset itself.

Replication improves resilience

Multiple copies let the system survive node loss and absorb more reads, but introduce lag and failover complexity.

Sharding raises the ceiling

Partitioning data across nodes lets the system store and write more than one box can handle, but makes routing and rebalancing harder.

They solve different bottlenecks

Replication helps when the same data is being read too often. Sharding helps when one node cannot hold or write the whole dataset anymore.

Key takeaways

  • Replication is about copies. Sharding is about splitting.
  • Read scale and write scale are different problems.
  • Failover, lag, and consistency become more visible with replication.
  • Shard keys determine whether scaling is smooth or painful.