← All posts

15 Jun 2026 · Rehurz

A Beginner's Guide to Database Sharding and Replication

When you design a system to serve millions of users, a single database eventually becomes a bottleneck. You need to scale. Two fundamental strategies appear in almost every system design interview: replication and sharding. They solve different problems, and understanding when and how to use each is critical to both building real systems and answering system design questions confidently.

This guide explains what replication and sharding are, how they differ, and how to reason about them when an interviewer asks, "How would you scale the database for this workload?"

Quick answer: Replication copies data across multiple databases to scale reads and improve availability; sharding partitions data across databases to scale writes and reduce storage per node. Replication is vertical scaling within similar nodes. Sharding is horizontal partitioning, splitting one dataset into subsets on separate nodes.

What is Database Replication?

Replication is the process of copying data from one database (the primary) to one or more other databases (replicas). All writes go to the primary. Reads can come from the primary or from any replica.

Replication serves two goals. First, it scales read capacity. If your primary handles 10,000 read requests per second but your users need 40,000, you can send reads to replicas and distribute the load. Second, it improves availability. If the primary fails, a replica can be promoted to take over. Your system stays up.

The mechanics of replication vary, but the principle is always the same: changes to the primary are copied to replicas. Some replication is synchronous (the primary waits for replicas to acknowledge before confirming the write), and some is asynchronous (the primary confirms immediately, and replicas catch up in the background). Synchronous is slower but safer. Asynchronous is faster but carries a small risk of data loss if the primary crashes before all replicas receive the update.

Here is a typical primary-replica architecture:

User Query (read) ---------> [Load Balancer]
                                  |
                    +-------------+----------+
                    |             |          |
                    v             v          v
              [Primary DB]   [Replica 1]  [Replica 2]
              (all writes)   (read-only)  (read-only)
                    |
                    | (binary log / write-ahead log)
                    +---->-|
                    |      |
                    v      v
            [Replication Stream]

Notice that writes still target the primary. Replicas receive copies of those writes asynchronously (in most setups). The primary remains the single source of truth.

What is Database Sharding?

Sharding is a horizontal partitioning strategy. Instead of one database holding all the data, you split the data into subsets and store each subset on a different database server. For example, if you shard by user ID, users 1 to 1 million go to Shard A, users 1 million to 2 million go to Shard B, and so on.

Sharding solves a different problem than replication. Replication does not reduce the storage or compute load on the primary. Every replica holds a full copy of the data. Sharding, by contrast, spreads the data across servers. Each shard holds a subset, so no single server is responsible for the entire dataset.

This is crucial when your data is so large that one machine cannot store it, or when your write throughput is so high that one server cannot handle all the writes. Replication alone will not fix this. You need to actually partition the data.

Here is how data might be split across three shards:

User ID 1-1000
Users Table:
+--------+-------+
| ID     | Name  |
+--------+-------+
| 1      | Alice |
| 500    | Bob   |
+--------+-------+
    |
    +------> [Shard 1: IDs 1-1000]

User ID 1001-2000
    |
    +------> [Shard 2: IDs 1001-2000]

User ID 2001-3000
    |
    +------> [Shard 3: IDs 2001-3000]

To query a sharded system, you must know which shard contains the data. If you want user 500, you compute which shard holds IDs 1 to 1000 (that is Shard 1) and query there. This is a fundamental constraint: sharded systems require application logic or a sharding service to route queries to the right shard.

Replication vs. Sharding: Key Differences

Here is a side-by-side comparison:

Aspect          | Replication       | Sharding
----------------+-------------------+----------------
Goal            | Scale reads       | Scale reads AND
                | Availability      | writes; partition
                |                   | data
Data on each    | Full copy         | Subset of data
node            |                   |
Write scaling   | No, single        | Yes, writes
                | primary           | distributed
Consistency     | All replicas      | Independent
                | see same data     | shards
Failover        | Promote replica   | Route to replica
                |                   | shard or rebuild
Complexity      | Moderate          | High (routing,
                |                   | resharding)

Replication is simpler. Sharding requires you to decide how to partition the data (which key to shard on?) and implement routing logic to send queries to the correct shard.

Replication Strategies

Primary-Replica Replication

One primary (all writes), many replicas (read-only). This is the most common pattern. The primary sends all changes to the replicas. Replicas lag slightly behind because updates are asynchronous, but this is acceptable for most read-heavy workloads.

Advantage: Simple. Disadvantage: write bottleneck at the primary.

Multi-Primary (Multi-Master) Replication

Multiple databases can accept writes. Changes replicate across all primaries. This is faster for writes but introduces complexity: what happens if two primaries write to the same row at the same time? You need a conflict resolution strategy (last-write-wins, custom merge logic, or application-level handling).

Advantage: No single write bottleneck. Disadvantage: conflict handling is hard.

Synchronous vs. Asynchronous

Synchronous replication waits for at least one replica to acknowledge before confirming a write. This ensures data is durable (you know the write is on multiple machines) but adds latency.

Asynchronous replication confirms the write to the primary immediately and replicates in the background. This is fast but carries a tiny window of risk. If the primary crashes before the replica receives the update, you lose that write.

Sharding Strategies

Range-Based Sharding

Assign ranges of a key to different shards. For example, user IDs 1 to 1 million on Shard 1, 1 million to 2 million on Shard 2. This is simple and makes range queries efficient (all data for a range is on one shard). The downside: if certain ID ranges become very popular, one shard can become hot (over-loaded) while others are idle.

Hash-Based Sharding

Hash the sharding key and map the hash to a shard. For example, hash(user_id) % 3 determines which of three shards holds that user. This distributes data more evenly than ranges, reducing hot shards. The downside: range queries now span multiple shards.

Directory-Based Sharding

Maintain a lookup table that maps keys to shards. For example, a table stores every user ID and which shard it lives on. This is flexible but adds overhead: every query must consult the directory first. The directory itself can become a bottleneck.

The Resharding Problem

Sharding creates a problem: what happens when you need to add more shards? If you have three shards and want to add a fourth, you cannot simply recompute hash(key) % 4. Many keys will map to different shards, and you must move data.

Consistent hashing is a technique to minimize data movement during resharding. Instead of a simple modulo, you hash both the key and the shard number onto a ring. When you add a new shard, only the keys adjacent to that shard on the ring need to move. This is more efficient than moving everything.

Consistency and Failover

Replication introduces eventual consistency. A replica may lag behind the primary by milliseconds or seconds. If you query a replica immediately after writing, you might get stale data.

Sharding does not inherently create consistency issues (each shard is independent), but if you combine sharding with replication (which is common), you now have eventual consistency across the entire system.

Failover (handling failures) differs too. With replication, if the primary fails, you promote a replica. With sharding, if one shard fails, that shard becomes unavailable. If your sharding key is user ID and Shard 2 crashes, all users on Shard 2 are blocked until the shard recovers or you failover to a replica of that shard.

Real systems usually combine both: you shard the data, and each shard has replicas for availability.

When to Use Each

Use replication when:

  • You have more reads than writes, and a single primary can handle all writes.
  • You want high availability and can tolerate eventual consistency on reads.
  • Data fits on one machine.

Use sharding when:

  • Writes are too frequent for one primary to handle.
  • Data is too large for one machine.
  • You need geographic distribution (each region gets its own shard).

Use both when:

  • Data is huge, writes are frequent, and you need availability (the typical case for large systems).

Reasoning About This in an Interview

When a system design interviewer asks how you would scale the database, think through this checklist:

  1. Read vs. write heavy? If mostly reads, replication alone may suffice. If many writes, you need sharding.
  2. How much data? If it fits on one (large) machine, replication is enough. If it is terabytes, sharding is necessary.
  3. Consistency requirements? Can you tolerate eventual consistency? Replication gives you that for free. If you need strong consistency, replicas complicate the design.
  4. Geographic distribution? If users span multiple continents, sharding by region makes sense so that reads are local.
  5. Failover strategy? Replicas give you a backup. Shards do not; you need replicas per shard for availability.

A good answer acknowledges the tradeoffs. For example: "I would shard by user ID using hash-based sharding to distribute writes. Each shard would have two replicas for availability. Reads would go to any replica in the replica set for that shard. Writes would go to the primary replica. If the primary fails, we promote one of the secondaries. This gives us write scalability via sharding and read scalability plus availability via replication."

Frequently Asked Questions

What is the difference between replication and sharding again?

Replication copies the entire dataset to multiple machines. Sharding splits the dataset across machines. Replication scales reads and improves availability. Sharding scales both reads and writes and lets you store very large datasets.

Is eventual consistency a problem?

It depends on your use case. Social networks and analytics tolerate it. Banking and payments are trickier. A common pattern is to read from the primary after a write (higher latency but strong consistency) and read from replicas for non-critical queries.

Can you shard and replicate the same database?

Yes, and it is standard. You shard the data first (to distribute writes), then replicate each shard (for availability). Each shard acts as a primary with its own replicas.

How do you route queries to the correct shard?

At the application layer, you compute which shard a query belongs to (usually a hash of the sharding key), then send it to that shard. Alternatively, a proxy layer can handle this transparently.

What happens if resharding takes too long?

During a reshard, some data is in transit. Queries may return partial results or timeout. This is why consistent hashing is valuable: it minimizes the amount of data that must move. Some systems use double-writes (write to both old and new shard layouts) during migration to reduce downtime.

How many shards do you need?

Start with enough to handle your current write load and future growth (maybe 2 to 4 years ahead). Too many shards adds operational complexity. Consensus is to aim for 16 to 64 shards for most systems, but this varies.

Practising This with Rehurz

System design interviews often include databases. An interviewer might ask, "Design a social media platform. How would you scale the user table?" You need to walk through the tradeoffs: sharding strategy, replica count, consistency model, failover.

On Rehurz, you can practise this as a spoken technical round. You design the system out loud, and the interviewer asks follow-up questions: "What if you need to reshard? How would you handle a shard failure? Why not use multi-primary replication?" The interview adapts to your answers, so you get real cross-questioning on the assumptions you make.

The scorecard rates you on "System Design," measuring your ability to reason about tradeoffs, defend your choices, and adapt under pressure. Start a live technical interview, and your first one is free. Sign up to get started.

As systems grow, the database becomes the hardest part to scale. Replication and sharding are not the only tools (caching, message queues, denormalization all help), but they are foundational. Mastering them makes you a stronger engineer and a more confident interviewee.