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.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
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
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
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 ask about
- 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 (L5/E5)
- 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 (L6+/E6+)
- 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.