System design · Day 8
Replication and partitioning: grow beyond one database
Understand read replicas, consistency lag, sharding keys, and the trade-offs that appear when data spans machines.
One database is a strong default. Replication and partitioning become relevant only after measurement shows that availability, read volume, or data size has outgrown that default.
Replication makes copies for reads and recovery
In leader-follower replication, writes go to a leader and changes flow to followers. Followers can serve reads and replace the leader after failure. This improves read capacity and availability without changing the logical data model from Day 5.
Replication is often asynchronous, so a follower may be behind. A user who updates a profile and immediately reads from a follower could see the old value. Route read-after-write traffic to the leader or track a replication position when fresh data matters.
Partitioning divides ownership
Partitioning, or sharding, splits rows across database nodes. A shard key decides where each record lives. Good keys distribute load evenly and match common queries; poor keys create hot shards or force expensive requests across every partition.
User ID is often a useful key for user-owned data. Time can be dangerous when all new writes land on the newest shard. Hashing spreads traffic but makes range queries harder. The access patterns—not fashion—should choose the key.
Distribution creates coordination costs
Cross-shard transactions, global uniqueness, rebalancing, and backups all become harder. That is why caching from Day 6 and careful queries should be exhausted before sharding. Scaling the simplest layer is usually safer than introducing a new distributed guarantee.
Replicas and shards also create more failure modes. Day 9 turns those failure modes into a concrete reliability strategy with timeouts, failover, monitoring, and graceful degradation.