# Replication vs Sharding > Replication keeps copies of the same data; sharding splits data into subsets that different servers own. Use replication for fault tolerance and, when consistency requirements allow, read scaling; use sharding when storage or write load exceeds one server’s capacity. They are complementary: production designs often replicate each shard. Source: https://sysround.com/compare/replication-vs-sharding Updated: 2026-11-05 ## Side by side | | Replication | Sharding | |---|---|---| | Data placement | Multiple copies of the same dataset | Different subsets assigned to different shards | | Primary purpose | Fault tolerance and read scaling | Distribute storage and write load | | Storage capacity | Copies consume space without increasing unique-data capacity | Adds capacity for distinct data | | Write throughput | Single-leader replicas still apply the same writes | Independent shards can process writes in parallel | | Read path | Choose a replica with acceptable freshness | Route by shard key or query multiple shards | | Failure handling | Failover depends on acknowledgment and election rules | Without replicas, a failed shard makes its data unavailable | | Consistency and transactions | Coordinate copies; handle lag and failover | Cross-shard transactions require extra coordination | | Operational challenge | Replica lag, promotion, and split-brain prevention | Shard-key choice, skew, routing, and resharding | ## The differences that matter Replication duplicates work as well as data. In a single-leader database, every replica must apply the leader’s writes, so adding followers does not divide the write workload. Followers can serve eligible reads, but read capacity depends on replication overhead, query cost, and freshness requirements. Sharding distributes ownership. Hashing by customer ID can spread customers across shards and keep customer-scoped queries local. A query without the shard key may need to contact every shard, merge results, and tolerate slow or unavailable participants. Replication changes the write-acknowledgment and failure model. Asynchronous replication can acknowledge a write before another copy has it, so failover can lose acknowledged writes. Synchronous replication can protect against specified failures, but adds coordination latency and may block writes when required replicas are unreachable. Sharding changes transaction boundaries and growth operations. Transactions within one shard can remain local; transactions across shards need distributed coordination or an application-level workflow. Adding shards also requires moving data safely while reads and writes continue, and a poor shard key can leave one shard overloaded. ## Choose Replication when - The dataset and write workload fit on one server, but the service must survive a server failure. - Reads dominate, and enough reads can use followers under an explicit freshness policy. - You need additional copies in separate failure domains for recovery or regional access. - You want to preserve a single logical transaction boundary rather than introduce cross-shard operations prematurely. ## Choose Sharding when - The dataset, including indexes and growth headroom, exceeds a single server’s practical storage capacity. - Write CPU, disk throughput, or working-set pressure exceeds one server’s capacity after reasonable tuning. - A stable shard key distributes load and keeps the most important queries and transactions local. - You need to spread tenants or key ranges across independently managed capacity, while also replicating shards for availability. ## Worked example: Growing a customer database beyond one server Suppose a customer database holds 2 TB including indexes, while each database server has a 500 GB usable storage budget. Three full replicas do not solve the capacity problem: each still needs to hold 2 TB. Splitting the dataset into eight shards gives about 250 GB per shard if customers are evenly distributed. Keeping three total copies of each shard requires about 6 TB of aggregate storage before extra operational headroom. Route customer-scoped reads and writes by customer ID. Replication handles individual server failures; sharding handles capacity. A disproportionately large customer may still require isolation or a finer partition key. ## In the interview - Name the bottleneck before choosing: unique-data size, write throughput, read throughput, or failure tolerance. Replication and sharding address different constraints. - Draw ownership and copies separately. For example, show four shards with three replicas each, then explain that replica instances may share machines subject to capacity and failure-domain constraints. - For replication, state where reads go, when writes are acknowledged, and how a new leader is selected without allowing two active leaders. Expect questions about stale reads and acknowledged-write loss. - For sharding, name the key and trace the main queries through it. Expect questions about large tenants, hot keys, cross-shard transactions, and online resharding. ## Common mistakes - Treating replication and sharding as mutually exclusive alternatives instead of independent design choices. - Claiming that more single-leader replicas proportionally increase write throughput or unique-data capacity. - Assuming sharding fixes every hotspot. One heavily written key still belongs to one shard unless the data model changes. - Calling replicas backups or assuming replicas guarantee zero data loss. Deletes and corruption can propagate, and durability depends on acknowledgment and failure assumptions. ## Interview questions where it comes up - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): A strong answer separates partition ownership from replica placement, then explains routing, durability, and recovery. - [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): Partitioning spreads the working set while replicas support failover and eligible reads without automatically solving hot keys. - [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): Partitions provide parallelism and per-partition ordering, while replication protects each partition’s log during failures. - [Design a URL shortener like Bitly](https://sysround.com/questions/design-url-shortener): The design must distinguish distributing URL mappings across shards from replicating mappings for availability and read traffic. - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Shard placement, replica health, safe promotion, and capacity expansion become explicit control-plane responsibilities. ## FAQ ### Can replication and sharding be used together? Yes. Sharding determines which subset of data a group owns, while replication maintains copies of that subset. Each shard can have its own leader and followers, with replicas placed across failure domains. ### Does replication improve write performance? In a single-leader system, adding followers generally does not increase write throughput because each follower applies the same write stream. Multi-leader or leaderless designs can accept writes at multiple nodes, but coordination and conflict handling still constrain performance. Sharding is the more direct way to divide independent writes across owners. ### Should I use replication or sharding first? If the data and write load fit on one server, replication is often the first step for availability and eligible read traffic. Add sharding when measured capacity limits or isolation requirements justify its routing and operational complexity. If the initial workload already exceeds one server, design for sharding from the start. ## Related concepts - [Database replication](https://sysround.com/concepts/replication) - [Database sharding](https://sysround.com/concepts/database-sharding) - [Partitioning strategies](https://sysround.com/concepts/data-partitioning) - [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys) - [Quorums](https://sysround.com/concepts/quorums) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.