Database Sharding & Replication

A single database server eventually can't hold all your data or handle all your traffic. Sharding and replication are how you scale beyond it.

Replication: Copies for Reads and Redundancy

A primary-replica setup lets replicas serve read traffic while the primary handles writes, improving read throughput and providing failover if the primary goes down. The trade-off is replication lag — replicas may briefly serve stale data.

Sharding: Splitting Data Across Servers

Sharding partitions your dataset across multiple database instances, typically by a shard key (like user ID). This lets you scale writes horizontally, but cross-shard queries and joins become significantly harder.

The join problem is worth stating explicitly in an interview: a query that used to be a single SQL join across two tables now has to fetch data from two potentially different shards and combine the results in application code, or you denormalize the data ahead of time to avoid the cross-shard lookup entirely. Naming this trade-off shows you understand sharding isn't free.

Picking a Shard Key

A good shard key distributes load evenly and matches your most common query pattern. A poor choice creates "hot shards" that receive disproportionate traffic — a classic system design interview pitfall worth explicitly calling out.

Resharding Is Expensive — Plan for It

As data grows, you may need to add shards and redistribute data across them. Consistent hashing minimizes how much data has to move when the number of shards changes, compared to naive modulo-based sharding where nearly everything moves.

Replication and Sharding Work Together

These aren't competing techniques — most large systems shard for write scale and replicate within each shard for read scale and redundancy. Mentioning that they compose is a strong signal of real distributed systems experience.

Synchronous vs Asynchronous Replication

Synchronous replication waits for a replica to confirm before acknowledging a write — safer, but slower and vulnerable to a slow replica dragging down every write. Asynchronous replication acknowledges immediately and replicates in the background — faster, but a primary failure can lose the most recent writes that hadn't replicated yet. Stating which one fits your system's tolerance for data loss versus latency is a strong follow-up point.