# Design a database replication system: system design interview question

> Database updates across sites: transaction order, replica lag, safe failover, and replica recovery while writes continue.

Source: https://sysround.com/questions/design-database-replication-system
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a system that continuously copies database updates to read replicas and a disaster recovery site. Explain how the system handles replication lag, failover, and replicas that need to recover."

## What to clarify first

- Engine and scope
- Topology and database size
- Workload and read:write ratio
- Network and recovery capacity
- Request latency
- Replica read consistency
- Durability and data loss
- Availability during a remote failure
- Log retention
- Recovery time

## Scope of a strong answer

Core requirements:

- Copy committed database updates to read replicas and a DR replica
- Serve replica reads without partial transactions
- Detect replica lag and promote replicas under a defined data loss policy
- Recover replicas after a crash, a network outage, or loss of required logs

Usually out of scope:

- Query execution and database indexes
- Multiple writable primaries
- Database sharding
- Historical backup service
- Replication across incompatible engine formats

## What interviewers probe

### Replica progress and transaction visibility

A replica can receive bytes before it stores or applies them. Confusion between these states causes false durability claims and partial reads.

### Failover authority

A network fault can leave the old primary alive. DR promotion permits data loss that home failover must prevent.

### Replica resynchronization

A large copy takes hours while the primary changes. The replica needs a valid database image and every required update after that image.

### Replication lag and restoration time

Durable lag determines possible data loss. Unapplied data determines replay time, so current data on disk does not ensure fast restoration.

## Common mistakes

- The design copies row changes without transaction order or atomic visibility.
- The design treats received, durable, and applied positions as the same state.
- The design promises zero data loss from asynchronous DR replication.
- The design promotes a replica without a safe election or a fence against old writers.
- The design copies a live database without a consistent image and a log boundary.
- The design bounds durable lag but ignores replay work within the restoration budget.

## The bar by level

- **Senior:** Defines write acknowledgment rules and safe home elections. Handles duplicate records, interrupted copies, missing logs, and stale replica reads. Calculates replay capacity and the full restoration budget.
- **Staff+:** Defines authority across regional failure and return. Enforces the replay backlog policy and explains its effect on RPO. Requires proof of isolation and explicit loss approval. Plans membership recovery and states when protection targets no longer hold.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=database-replication


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.