30-Second Glance
- Replication exists for three reasons: survive downtime/crashes without losing data, and serve far-away users with low latency.
- Life with replicas buys you redundant data (no loss on crash) plus higher read throughput.
- Synchronous replication waits for every replica (x=4 everywhere) before a write counts — safe but slow.
- Asynchronous replication acks after the leader write and propagates later — fast, but readers can see stale values (x=3).
- Most modern apps choose async for speed and then deal with lag and stale reads elsewhere in the stack.
Why replication?
- Downtime
- Pretty easy to loose the data is a server or DB crashes.
- Users can be living far away from where DB is hosted, hence request and response is taking a lot of time for them.
Life with replication(many databases)
- Redundant data : no lost data
- Increased DB throughput.
Synchronous and Asynchronous replication.
- In synchronous replication, we don't consider the write valid until and unless every replica has the copy of the value (in this case, ).
- In asynchronous replication, when we write the value to the database and hear from the DB we consider the write valid and asynchronously replicate , to the other database and meanwhile the user can read the stale(old, ) value.
- Writes takes a lot of time in synchronous replication, hence asynchronous replication is used in most of the modern applications because user can atleast read the data meanwhile the write propagates.
How do we replicate??
Trade-offs
| Approach | Pros | Cons | Use when |
|---|---|---|---|
| No replication (single DB) | Simple, no lag or conflicts | Data loss on crash, downtime, slow for distant users | Toy apps, throwaway prototypes |
| Synchronous replication | Every replica agrees before ack; no stale reads | Writes are slow; leader blocks on slowest replica | You need durability over speed (ledger-style writes) |
| Asynchronous replication | Fast writes; users can keep reading during propagation | Stale reads; risk of losing unpropagated writes on crash | Default for modern read-heavy apps that tolerate lag |
| Geo-replicated copies | Low latency for distant users; survives regional outage | More replicas to lag, monitor, and keep consistent | Users spread across continents |
Interview One-Liners
Q: Why replicate a database at all? A: To survive downtime/crashes without losing data and to serve geographically distant users faster.
Q: What does life with replication buy you? A: Redundant data (no single-crash loss) and increased DB read throughput.
Q: Synchronous vs asynchronous replication? A: Sync counts a write only after every replica has it — safe but slow; async acks after the leader write and propagates in the background — fast but readers may see stale values.
Q: Why do most modern apps pick async replication? A: Because writes stay fast and users can at least keep reading (possibly stale) data while the write propagates.
Q: What anomaly does async replication introduce? A: Stale reads — e.g. a reader sees x=3 after a newer x=4 was already acknowledged.