Database Scaling (Sharding & Replication)
Splitting data across machines (sharding) and copying it across machines (replication) — solving two different scaling problems.
Try answering in your head first, then click a question to check the model answer.
Q1.Why does sharding scale write throughput while simple read replicas don't?(show answer)
Read replicas are full copies of the same data — every replica still receives every write, since they need to stay in sync, so replication doesn't reduce the write load on the primary. Sharding actually splits the data itself across independent databases, so each shard handles only the writes for its subset of data, letting total write capacity scale roughly with the number of shards.
Q2.What is replication lag, and what problem can it cause for an application?(show answer)
Replication lag is the delay before a write on the primary becomes visible on a read replica. It can cause a "read-your-own-write" inconsistency — a user writes data, then immediately reads it back from a lagging replica and doesn't see their own change, which looks like a bug. Mitigations include routing a user's own reads to the primary right after their write, or using "read your writes" session consistency.
Q3.What makes choosing a good shard key important, and what happens with a poor choice?(show answer)
A poor shard key (e.g. one with highly uneven value distribution, or one that doesn't match query patterns) causes "hot shards" — some shards receive disproportionate load while others sit idle, defeating the purpose of spreading load evenly. It can also force many queries to fan out across every shard (since the query's filter doesn't align with the shard key), which is much more expensive than querying a single shard.
Q4.Why do cross-shard joins and transactions become significantly harder after sharding?(show answer)
Once related data lives on different physical database instances, a join or a transaction spanning that data can no longer rely on a single database engine's built-in join logic or ACID transaction guarantees — it requires the application (or a distributed coordination layer) to fetch from multiple shards and combine results, or use distributed transaction protocols (like two-phase commit), both of which are slower and more complex than a single-database join.