Sharding & Replication

Once a single database can't keep up, two techniques carry the load: replication (copy the data) and sharding (split the data). Interviewers use these to test whether you can grow a database beyond one machine — and whether you understand the costs.

The core idea

Replication keeps multiple copies of the same data on different nodes. It boosts read throughput and availability — if one copy dies, another serves. Sharding (partitioning) splits one large dataset into disjoint pieces (shards) spread across nodes, so each holds only a fraction. Sharding tackles write scaling and storage; replication tackles reads and fault tolerance. Big systems use both together.

Beginner — replication topologies

• Primary-replica (master-slave) — one primary takes writes and streams changes to read-only replicas. Reads scale out; writes still funnel through the primary.
• Multi-primary (multi-master) — several nodes accept writes; higher write availability but risks write conflicts that need resolution.

Replication can be synchronous (wait for replicas to confirm — safer, slower) or asynchronous (don't wait — faster, but replicas lag, causing possible stale reads).

Intermediate — sharding strategies

• Range-based — partition by a key range (e.g., users A–M vs N–Z). Simple, but uneven ranges cause hotspots.
• Hash-based — hash the key to pick a shard. Even distribution, but range scans get hard and resharding moves lots of data.
• Directory-based — a lookup service maps keys to shards. Flexible, but the directory is another component to keep available.

Advanced — the hard parts

Sharding introduces cross-shard JOINs and transactions, which are slow or need distributed protocols. A bad shard key creates hotspots or celebrity-key problems. Rebalancing when adding nodes is disruptive (which is why consistent hashing helps). Replication introduces replication lag and, with async, the choice between reading from the primary (fresh) or a replica (fast but possibly stale). With multi-primary you must resolve write conflicts.

Worked example

A messaging app's single DB can't handle write volume. You shard by user_id (hash-based) across four nodes so writes spread evenly, and give each shard two async read replicas for read scaling and failover. A user's messages live on one shard; that shard's primary takes writes while replicas serve history reads. If a primary fails, a replica is promoted.

When to use

Add replication first — it's simpler and covers reads plus availability. Add sharding only when a single node truly can't hold the data or absorb the write rate, since it adds real operational complexity. Choose the shard key by your dominant access pattern.

Tricks and mnemonic

Remember "Replicate for reads and resilience; shard for size and writes." Sharding = splitting (disjoint pieces); replication = copying (same data many times).

Fast revision of scaling a database beyond one machine.

• Replication = multiple copies of the same data → boosts read throughput and availability.
• Sharding = split data into disjoint pieces across nodes → boosts write scaling and storage.
• Topologies: primary-replica (one writer) and multi-primary (many writers, conflict risk).
• Sync replication is safe but slow; async is fast but causes replication lag (stale reads).
• Shard strategies: range (simple, hotspots), hash (even, hard scans), directory (flexible, extra component).
• Hard parts: cross-shard JOINs/transactions, shard-key choice, rebalancing.
• Replication does NOT add storage or primary write capacity — only sharding does.

Cover the answer, recall, then check. 8 cards.

Q1. What problem does replication primarily solve?
A1. Read scaling and availability (fault tolerance) via multiple copies of the same data.

Q2. What problem does sharding primarily solve?
A2. Write scaling and storage capacity by splitting data into disjoint shards.

Q3. In primary-replica replication, where do writes go?
A3. All writes go to the single primary, which streams changes to read-only replicas.

Q4. Synchronous vs asynchronous replication?
A4. Sync waits for replicas to confirm (safe, slower); async doesn't wait (fast, but replicas lag).

Q5. Name three sharding strategies.
A5. Range-based, hash-based, and directory-based.

Q6. What is a hotspot in sharding?
A6. A shard receiving disproportionate load due to an uneven key distribution.

Q7. Does replication increase total write throughput on the primary?
A7. No — every write still goes through the primary; only sharding splits writes.

Q8. What is replication lag?
A8. The delay before a change on the primary appears on async replicas, causing possible stale reads.

Worked Example

Problem: A users table has grown to 500 million rows — too big and too busy for one database node. Design a scheme that scales storage/writes AND survives a node failure.

Solution: Combine two orthogonal techniques.

Sharding (horizontal partitioning) splits the data across N nodes so each holds a slice. Shard by a hash of user_id, which spreads rows and write load evenly and lets a lookup go straight to the owning shard. Keep each user's related data co-located on the same shard to avoid expensive cross-shard joins.

Replication copies each shard to followers: give every shard 1 primary + 2 replicas. The primary takes writes; replicas serve reads (read scaling) and can be promoted if the primary fails (high availability).

Because plain hashing makes adding a shard painful (mass re-mapping), use consistent hashing for the shard assignment.

Answer: Hash-shard by user_id across N nodes, each with a primary and 2 replicas.