Database Scaling (Sharding & Replication)
Splitting data across machines (sharding) and copying it across machines (replication) — solving two different scaling problems.
Replication
Replication copies the same data onto multiple machines. A primary-replica setup routes writes to one primary node, which propagates changes to read replicas — scaling read throughput, since reads can be served by any replica, though replicas may lag slightly behind the primary (replication lag).
Sharding
Sharding splits data across machines by some key (e.g. user_id % N, or a range of IDs) so each machine holds only a subset of the total data — this scales both read and write throughput and total storage, at the cost of much harder cross-shard queries and joins.
They solve different problems
Replication scales read throughput and adds redundancy for a dataset that still fits on one machine. Sharding scales write throughput and total data size beyond what one machine can hold. Large systems typically combine both: each shard is itself replicated.
The real cost of sharding
Queries that need data from multiple shards (a join, or "top 10 across all users") become significantly more complex and slower — sharding is usually adopted only once a single database can no longer handle the write load or data volume, not by default.
Prerequisite
Assumes the horizontal-scaling vocabulary from Scalability Fundamentals, applied specifically to the database layer.