System Design · Architecture under constraints
How do you plan disaster recovery with RTO and RPO?
Short answer
RTO is how long recovery may take; RPO is how much data loss is acceptable. Choose backup, pilot light, warm standby or active-active, then test failover and failback against those targets.
Disaster recovery starts with two numbers. Recovery time objective is the maximum acceptable downtime. Recovery point objective is the maximum acceptable data loss, measured in time. A payment system may need an RPO of zero and an RTO of minutes; an internal analytics dashboard may tolerate hours.
Strategies, from cheapest to most available
- Backup and restore: periodic backups in another region, slowest recovery but lowest cost
- Pilot light: core data and configuration replicated, with minimal compute ready to scale up
- Warm standby: a scaled-down but functional copy of the full stack, promoted on failure
- Active-active: both regions serve traffic, requiring conflict-free data and global routing
- Multi-region active-passive: one region serves, the other is ready, with a controlled promotion
RPO drives replication. Asynchronous replication can lose the tail of writes, so an RPO of zero requires synchronous replication or a consensus commit across the required replicas. That choice costs latency and can reduce availability when a replica is slow. State the trade-off rather than claiming zero loss without paying for it.
Failover is a distributed-systems operation, not a switch. DNS changes are cached, so clients may keep hitting the failed region. The promotion must ensure the new primary has all acknowledged writes and that the old primary cannot continue accepting them, using fencing or a quorum. Failback needs its own plan, including resynchronization in the reverse direction.
Backups are not recovery unless they are tested. Run restore drills, verify checksums and measure the actual time to restore. A backup that has never been restored is an assumption. Also test partial failures: a lost database, a corrupted index, a deleted object store bucket and a revoked provider credential.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How does RPO affect the replication mode you choose?
- 2Why is DNS failover alone insufficient?
- 3How do you prevent the old primary from accepting writes after promotion?
- 4What would you test in a disaster recovery drill?
Say it in the interview
RTO and RPO turn disaster recovery into engineering targets: how long we can be down and how much data we can lose. The strategy follows from those numbers, from backup and restore through warm standby to active-active. RPO zero requires synchronous or consensus replication, which costs latency and availability, so I state that trade-off explicitly. I also test failover, failback and restore, because an untested backup is just a hope.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.