Replication: Why, and Synchronous vs. Asynchronous
Why this matters: replication is how a database survives a dead node and serves reads at scale. It is also where durability quietly stops being guaranteed, and most engineers do not notice which side of that line their system is on.
Key takeaway
Replication means maintaining multiple copies of data across different nodes, often geographically distributed, to improve availability, scalability, and performance.
What a data store must provide
Organizations need timely access to data despite increasing load, hardware failures, and network outages. Three characteristics are required:
- Availability — resilience against faults: disk, node, network, or power failures.
- Scalability — the ability to handle increasing reads, writes, and traffic.
- Performance — low latency and high throughput.
Achieving all three on a single node is often impossible. That is the entire case for replication.
The benefits
- Places data closer to users, reducing latency.
- Lets the system operate despite node failures, improving availability.
- Enables multiple nodes to serve reads, increasing read throughput.
The complexity it introduces
Replication is simple when data changes infrequently — for immutable data it is a one-time copy. The difficulty is entirely in propagating updates consistently. Mutable data requires careful handling of concurrency, failures, and inconsistencies.
The questions replication forces you to answer:
| Question | Where it's answered |
|---|---|
| How do we keep multiple copies consistent? | The replication model — Lessons 6 to 8 |
| How do we handle replica failures? | Failover and leader election — Lesson 6 |
| Should replication be synchronous or asynchronous? | This lesson |
| How do we manage replication lag? | Read-your-writes routing — Lesson 6 |
| How do we handle concurrent writes? | Conflict resolution and quorums — Lessons 7 and 8 |
| What consistency guarantees do we expose to developers? | The whole chapter, and Foundations |
Synchronous vs. asynchronous
There are two ways to disseminate changes to replica nodes.
In synchronous replication, the primary waits for acknowledgments from secondaries confirming the data has been updated. Only after receiving those acknowledgments does it report success to the client.
In asynchronous replication, the primary does not wait — it reports success immediately after updating itself.
| Synchronous | Asynchronous | |
|---|---|---|
| Primary waits for acks | ||
| Replicas fully up to date | ✗ — they lag | |
| Write latency | Higher — bounded by the slowest replica | Low — primary only |
| If a secondary is down or partitioned | Primary must wait before responding | Writes succeed anyway |
| If the primary fails | No unreplicated writes to lose | Unreplicated writes are lost |
| Durability guaranteed | No |
The advantage of synchronous replication is that all replicas stay fully up to date. The cost is that a secondary failing to acknowledge — through a fault or a network partition — forces the primary to wait, increasing write latency. Asynchronous replication acknowledges immediately even when secondaries are unavailable, at the price of losing any unreplicated writes if the primary dies.
Key takeaway
Synchronous replication trades latency for durability; asynchronous trades durability for latency. Know which one your database is configured for, because the answer determines whether an acknowledged write can vanish.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We replicate the database so there's a backup copy." |
| L5 | Knows the trade: "async replication so writes stay fast, accepting that we could lose recent writes if the primary dies." |
| Staff+ | Makes it a decision, not a default: "async is the usual default and it silently weakens durability — an acked write can be lost. For the ledger I'd use semi-sync so the loss window needs two simultaneous failures, and keep async for data where we can tolerate it." |
Next: the model almost every relational deployment uses.