What is Database Replication in System Design?
Learn database replication in system design: primary-replica model, sync vs async trade-offs, replication lag, and failover explained.
Expected Interview Answer
Database replication is the process of copying data from a primary database to one or more replica databases so the system gains redundancy for fault tolerance, additional read capacity, and geographic locality, at the cost of managing replication lag and consistency trade-offs.
In the common leader-follower (primary-replica) setup, all writes go to the primary, which streams a change log (a write-ahead log or binlog) to replicas that apply the same changes to stay in sync. Reads can be distributed across replicas to scale read throughput, since most systems are read-heavy. Replication can be synchronous, where the primary waits for a replica to confirm before acknowledging a write, guaranteeing no data loss but adding latency, or asynchronous, where the primary acknowledges immediately and replicas catch up shortly after, which is faster but introduces replication lag and a small window of possible data loss on primary failure. Multi-leader and leaderless replication topologies exist for systems that need writes to succeed in multiple regions, trading stronger consistency for availability and lower write latency, per the CAP theorem. Replication also underpins failover: if the primary dies, a replica is promoted to take over.
- Provides fault tolerance via redundant copies of data
- Scales read throughput by distributing reads across replicas
- Reduces latency by serving reads from a geographically nearby replica
- Enables fast failover by promoting a replica when the primary fails
AI Mentor Explanation
Database replication is like a stadium keeping the official scorebook at the scorer table (the primary) while runners carry updated copies to scoreboards around the ground (replicas) after every over. Fans near any scoreboard can check the score without crowding the scorer table, spreading out the read load. If a runner is a little behind, that scoreboard briefly shows a slightly older score, which is replication lag. If the scorer table itself is knocked over, one of the scoreboard copies can be declared the new source of truth, just like promoting a replica.
Step-by-Step Explanation
Step 1
Write hits the primary
All write operations are sent to the primary database, which is the single source of truth for writes.
Step 2
Change log streamed
The primary streams a write-ahead log or binlog of changes to each replica.
Step 3
Replicas apply changes
Each replica applies the log entries in order, either synchronously or asynchronously relative to the primary.
Step 4
Reads distributed and failover ready
Read traffic is spread across replicas; if the primary fails, a replica is promoted to become the new primary.
What Interviewer Expects
- Clear leader-follower model: writes to primary, reads distributed across replicas
- Synchronous vs asynchronous replication trade-off (consistency vs latency)
- Understanding of replication lag and its consequences for stale reads
- Awareness of failover: promoting a replica when the primary fails
Common Mistakes
- Confusing replication with sharding (replication copies the same data; sharding splits it)
- Assuming replicas are always perfectly up to date
- Not discussing the synchronous/asynchronous trade-off
- Forgetting to mention failover and replica promotion
Best Answer (HR Friendly)
“Database replication means keeping copies of the same data on multiple servers, with one primary handling writes and the copies, called replicas, staying in sync to handle reads. This gives the system redundancy if a server fails and lets it handle more read traffic, though the copies can lag slightly behind the primary depending on how the syncing is configured.”
Code Example
services:
db-primary:
image: postgres:16
environment:
POSTGRES_REPLICATION_MODE: master
POSTGRES_REPLICATION_USER: replicator
command: ["postgres", "-c", "wal_level=replica", "-c", "max_wal_senders=5"]
db-replica-1:
image: postgres:16
environment:
POSTGRES_REPLICATION_MODE: slave
POSTGRES_MASTER_HOST: db-primary
depends_on:
- db-primary
db-replica-2:
image: postgres:16
environment:
POSTGRES_REPLICATION_MODE: slave
POSTGRES_MASTER_HOST: db-primary
depends_on:
- db-primary
# Application config: writes -> db-primary, reads load-balanced across replicasFollow-up Questions
- What is the difference between synchronous and asynchronous replication?
- How does replication lag cause read-your-own-writes problems, and how do you fix it?
- How does replication differ from sharding?
- What happens during failover when the primary database fails?
MCQ Practice
1. In a leader-follower replication setup, where do writes go?
All writes are directed to the primary, which then propagates changes to replicas, keeping a single source of truth for writes.
2. What is replication lag?
Replication lag is the gap between when data is written on the primary and when it is applied on a replica, most common in asynchronous replication.
3. What is the main trade-off of synchronous replication?
Synchronous replication waits for the replica to acknowledge before confirming the write, which prevents data loss but slows down writes.
Flash Cards
What is database replication? — Copying data from a primary database to one or more replicas for redundancy and read scaling.
Synchronous replication trade-off? — No data loss, but higher write latency waiting for replica confirmation.
Asynchronous replication trade-off? — Lower write latency, but risk of replication lag and small data loss on primary failure.
What happens on primary failure? — A replica is promoted to become the new primary, a process called failover.