Skip to main content

Data Replication

Replication keeps copies of the same data on multiple machines. Where Database Sharding splits different data across machines to scale capacity, replication puts the same data on multiple machines — and the two solve genuinely different problems: sharding scales how much data you can hold and write, replication scales how many reads you can serve and how well the system survives a machine dying. Most large systems eventually need both, layered together.

Why replicate at all​

A single database instance is a Single Point of Failure: if that one machine dies, the data is unavailable (or, without backups, gone). Replication directly addresses this — if one replica goes down, others still hold the data and can keep serving traffic, which is the same failover idea from Core Concepts, applied specifically to the database layer. It also scales read throughput: reads can be spread across several replicas instead of all landing on one machine, which is often the single highest-leverage move in Database Scaling before sharding is ever needed.

Leader-based replication: the standard pattern​

The most common setup designates one replica the leader (or primary), which accepts all writes, and one or more followers (or replicas), which accept only reads and continuously apply the stream of changes the leader produces.

System Design Lab

Directing all writes through one leader keeps write ordering simple and unambiguous — there's exactly one place a conflicting pair of writes could originate, so there's nothing to reconcile. The cost is that the leader is both a throughput ceiling for writes and, until a new leader is promoted, a single point of failure for them — which is exactly the failover scenario a well-designed replicated database needs an automated plan for.

Synchronous vs. asynchronous replication​

How a follower receives updates from the leader is its own real tradeoff, and it maps directly onto the CAP Theorem's consistency-vs-latency tension:

  • Synchronous replication — the leader waits for at least one follower to confirm it has the write before acknowledging the client. Guarantees a follower is always fully caught up, at the cost of added write latency (and reduced availability if that follower is unreachable).
  • Asynchronous replication — the leader acknowledges the write immediately and replicates in the background. Lower write latency, but a follower can lag behind — a read from it can return stale data, and if the leader dies before replicating a write, that write can be lost entirely.

Most systems use asynchronous replication as the default and reserve synchronous replication for data where losing a just-acknowledged write is genuinely unacceptable — the same kind of explicit tradeoff call that CAP Theorem forces on distributed systems generally.

Multi-leader and leaderless replication​

Single-leader replication isn't the only shape. Multi-leader replication accepts writes at more than one node (useful across geographically distant datacenters, so writes don't all have to cross an ocean), at the cost of needing conflict resolution when the same data is written differently in two places at once. Leaderless replication (used by Dynamo-style databases) accepts writes at any replica and uses quorum reads/writes to stay consistent enough, trading the simplicity of a single write path for higher write availability. Both of these get a fuller treatment in Database Architectures, which surveys how these replication topologies combine into complete system designs.

Keeping replicas honest​

Replication assumes followers actually match the leader's data over time, but network issues, bugs, or partial failures can cause silent drift. This is exactly where Checksums come back in: comparing checksums over ranges of data between the leader and a replica is a far cheaper way to detect divergence than shipping and diffing the raw data itself.

Why this matters in an interview​

"We'll add a read replica" is a fine starting instinct, but naming synchronous vs. asynchronous replication — and which one the design actually needs, given what staleness or write latency the application can tolerate — turns it into a specific decision instead of a reflex. It's also worth being ready to name what happens when the leader dies: an automated promotion process, and what (if anything) is lost in the failover.

Asynchronous vs. synchronous replication: pros and cons​

Asynchronous

  • Lower write latency — the leader doesn't wait on any follower
  • Leader stays available for writes even if a follower is slow or unreachable
  • The simpler, more common default for most workloads

Synchronous

  • Adds write latency, since the leader waits on follower acknowledgment
  • Reduces write availability if the synchronous follower becomes unreachable
  • More complex failure handling when the required follower is slow or down

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.