Explain RPO and RTO, and how they should drive your backup and disaster-recovery design.
What they are really testing: Whether you tie DR to business requirements (acceptable data loss and downtime) and let those numbers drive cost, rather than treating "we take backups" as a DR strategy. They also want to hear that an untested backup is not a backup.
A real interview question
Explain RPO and RTO, and how they should drive your backup and disaster-recovery design.
What most people say
drag me
“RPO and RTO are recovery metrics, and we handle DR by taking nightly backups of the database.”
It does not actually distinguish the two (one is data loss, one is downtime), and nightly backups quietly assume a 24-hour RPO that may be unacceptable. It never tests the restore, never protects the backup location, and treats "we have backups" as a DR strategy.
The follow-ups they ask next
The business says RPO and RTO of near-zero for everything. How do you respond?
Near-zero for everything means active-active everywhere, which is very expensive. Push back with a tiered approach: classify systems by criticality and assign each tier an RPO/RTO it can justify the cost of. Near-zero is reserved for the truly critical path.
You have backups but a recovery still took 8 hours against a 1-hour RTO. What went wrong?
The backups met RPO but the recovery process was never tested at scale, restoring large volumes, rebuilding indexes, reconfiguring networking, and DNS all take time. Fix it with rehearsed runbooks, a pre-provisioned (warm) target, and regular timed drills.
What the interviewer is listening for
- Cleanly separates data loss (RPO) from downtime (RTO)
- Lets business requirements drive cost, not the reverse
- Matches a DR pattern to the agreed numbers
- Insists on testing the restore and protecting backup copies
What sinks the answer
- Conflates RPO and RTO
- Treats "we have nightly backups" as a DR strategy
- Never tests a restore
- Stores backups alongside the primary with no isolation
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“RPO is [acceptable data loss, it sets backup frequency] and RTO is [acceptable downtime, it sets recovery speed]. Those numbers should [come from the business and drive the design]. I pick the cheapest DR pattern that meets them, from [backup-and-restore] up to [active-active]. I store backups [cross-region, encrypted, immutable] and I [run timed restore drills], because an untested backup is [not a recovery plan].”
Keep going with reliability
Foundation
What is a Region versus an Availability Zone, and why does the difference matter?
Foundation
What is the difference between vertical scaling and horizontal scaling, and when would you reach for each?
Foundation
What does "highly available" actually mean, and how do you achieve it?
Foundation
Why are stateless services easier to scale and make reliable than stateful ones?
Junior
How should a service retry a failed call to a dependency, and what is a retry storm?
Junior
What is idempotency, and why does it matter for reliable distributed systems?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free