Q&A

Data replication: Master-Slave

By AlgoInsight Team2026-06-07databases

Overview

As an application grows, a single database struggles to handle all traffic. Master-Slave replication scales reads by maintaining copies of the data: writes go to the master, which streams its changes to read-only replicas. Most apps are read-heavy, so distributing reads across replicas dramatically increases capacity, while the master remains the single source of truth for writes.

graph TD
    APP[Application] -->|writes| M[(Master / Primary)]
    APP -->|reads| S1[(Replica 1)]
    APP -->|reads| S2[(Replica 2)]
    M -->|replicate changes| S1
    M -->|replicate changes| S2
    style M fill:#1e1b4b,color:#fff

How It Works

1. All writes (INSERT/UPDATE/DELETE) go to the master.
2. The master records changes in a replication log (e.g. MySQL's binlog, PostgreSQL's WAL).
3. Replicas continuously pull/receive that log and apply the same changes, staying in sync.
4. The application routes reads to replicas and writes to the master.

Benefits

• Read scalability - add replicas to handle more read traffic.
• High availability / failover - if the master dies, a replica can be promoted to master.
• Backups without impact - run backups off a replica, sparing the master.
• Geographic distribution - place replicas near users to cut read latency.
• Analytics isolation - run heavy reporting queries on a replica.

The Central Trade-off: Replication Lag

Replication is usually asynchronous - the master doesn't wait for replicas to confirm. So a replica may be slightly behind ("lag"), and a read right after a write might return stale data:

1. User updates profile  → written to MASTER
2. Page reloads, reads   → from a REPLICA that hasn't applied the change yet
3. User sees their OLD profile (eventual consistency)

This read-your-writes problem is the classic gotcha. Mitigations:

• Route reads that must be fresh (e.g. right after a write) to the master.
• Use semi-synchronous replication (master waits for at least one replica to acknowledge) for stronger guarantees at some latency cost.
• Tolerate eventual consistency where it's acceptable.

Sync vs Async vs Semi-sync

Limitations

• Master is a single write bottleneck - replication scales reads, not writes. For write scaling you need sharding (partitioning data) or multi-master setups.
• Single point of failure for writes - until a replica is promoted, writes are blocked. Automated failover (e.g. orchestration tools) reduces downtime.
• Failover complexity - promoting a replica, redirecting traffic, and avoiding split-brain require care.
• Data loss window - with async replication, un-replicated writes can be lost if the master fails.

Related Patterns

• Multi-master / multi-primary - multiple nodes accept writes (more complex; conflict resolution needed).
• Sharding - horizontally partition data to scale writes.
• Terminology note: the community increasingly uses primary/replica instead of master/slave.

Why This Matters in Interviews

System-design interviews use this constantly. Cover: writes → master, reads → replicas; why (most workloads are read-heavy); the master streams its change log to replicas; and the central trade-off of replication lag / eventual consistency with the read-your-writes problem and its fixes (read-from-master for fresh data, semi-sync). Crucially, state that replication scales reads, not writes - write scaling needs sharding - and that the master is a single point of failure requiring failover. This depth distinguishes a strong answer.

Common Pitfalls

• Claiming it scales writes (it scales reads; the master still takes all writes).
• Ignoring replication lag and the stale-read / read-your-writes issue.
• Forgetting the master is a single point of failure without failover.
• Assuming replication is synchronous by default (it's usually async).
• Overlooking the data-loss window on async failover.

References

• MySQL Replication: https://dev.mysql.com/doc/refman/8.0/en/replication.html
• Designing Data-Intensive Applications (Kleppmann), replication chapter.

More answers