Replication and sharding are easy to confuse because they both sound like 'data scaling,' even though they remove very different limits.
This chapter separates read scale and availability from write scale, showing when replicas are enough, when you need a more complex write topology, how shard keys should be chosen, and why moving data is almost always a project of its own.
In architecture reviews and interviews, that framing helps you discuss lag, failover, hot shards, and rebalancing cost as parts of one decision rather than as a pile of isolated infrastructure tricks.
Practical value of this chapter
Data Boundary
Define the data boundary through shard-key choice and request shape so cross-shard work does not become a permanent tax on growth.
Replication Mode
Choose replication mode from acceptable lag, failover expectations, and the true cost of write conflicts.
Rebalancing Plan
Plan data movement, background migration, and safe cutover before the first hot shard forces the issue.
Decision Rationale
Show where reads scale, where writes scale, and which limit the system is likely to hit next.
Context
Design principles for scalable systems
This chapter zooms in on how data scaling turns into concrete replication choices, sharding schemes, and an operational evolution plan.
Replication and sharding can sound like the same conversation about data growth, but in practice they solve different problems. Replication helps with failure tolerance, read scaling, and data proximity. Sharding becomes necessary when a single data placement no longer fits the write rate, storage volume, or maintenance windows of one node.
The real design question is rarely “do we scale the database?” It is “where does scale break first, and what kind of complexity are we willing to buy to move that limit?” That is why leader-follower, multi-leader, and leaderless models should be compared together with lag, failover, and the operational cost of conflict handling.
On the sharding side, the key decision is not only how to split data today, but how the shard key and metadata service can evolve when access patterns change, one shard turns hot, or cross-shard workflows become unavoidable. Good design here is as much about future rebalancing as it is about the first distribution rule.
Replication Models
Primary-Replica
One primary write path with several read replicas. Useful when you need fast read scaling without making operations much harder.
You need to manage replica lag carefully and rehearse automated failover before it becomes an incident.
Multi-Primary
Writes are accepted in multiple regions or nodes. Useful when local write latency matters more than a simple topology.
Conflict resolution and version-merging logic raise platform and team complexity very quickly.
Leaderless
Reads and writes are acknowledged by multiple replicas. A common fit for highly available distributed KV/NoSQL systems.
You have to reason much more carefully about quorums, read repair, hinted handoff, and tombstone handling.
Replication Visualization
Sharding Models
- Hash-based sharding gives more even distribution, but makes range queries and local scans harder.
- Range-based sharding works well for ordered access and range queries, but individual ranges can overheat.
- Directory-based sharding gives you flexible placement control, but depends on a reliable metadata service.
- Geo/tenant sharding helps with isolation and placement rules, but makes cross-tenant and cross-region workflows more expensive.
Sharding Visualization
Related chapter
Performance Engineering
Hot shards and migration windows show up quickly as higher p95/p99 latency and user-visible instability.
Shard Rebalancing and Hot-Shard Control
Use consistent hashing and virtual nodes to reduce migration volume when node count changes.
Prepare for hot shards with adaptive partitioning, write buffering, time-based split, and more precise routing keys.
Run backfill and data migration through throttled background pipelines with checksum verification and a safe resume point.
Every rebalance operation should have a pause path, a rollback plan, and visible progress reporting.
Related chapter
Cost Optimization & FinOps
Replication topology and rebalance frequency directly affect network spend, storage duplication, and reserve capacity.
Checks Before Rollout
RPO and RTO are defined for each data class and each failure scenario.
The team has explicitly documented which operations require strong consistency and where controlled asynchrony is acceptable.
There is a shard-key evolution plan for product growth and changing access patterns.
Replication, failover, and rebalancing are rehearsed regularly through planned failure scenarios.
Cross-zone and cross-region replication cost is included in the operating model instead of being discovered later.
Common mistake: choosing a shard key only for today’s query mix without an evolution plan.
References
Related chapters
- Design principles for scalable systems - Helps place replication and sharding inside the broader scaling model instead of treating them as isolated database tricks.
- CAP Theorem - Explains the constraints that show up under network partitions and why the data model cannot ignore them.
- PACELC Theorem - Shows how latency and consistency still trade off even when the system is not in a failure state.
- Database Selection Framework - Connects database type to the replication modes, sharding options, and operating complexity you can realistically support.
- Multi-region / Global Systems - Useful when data has to be spread across regions while still meeting placement and resilience constraints.