Two Numbers That Drive DR
Two Numbers That Drive DR
RTO (Recovery Time Objective) is how long the service may be down before the business is harmed. RPO (Recovery Point Objective) is how much data you can afford to lose, measured backward from the failure — the age of the newest usable copy.
Example: an orders API with RTO 30 minutes and RPO 5 minutes must resume within half an hour, losing at most five minutes of writes. Translate each number to machinery: RPO ≤ minutes implies continuous replication; RPO ≈ hours fits scheduled backups. RTO ≈ minutes demands pre-built infrastructure and automated failover; RTO ≈ a day tolerates rebuilding from infrastructure as code. The strategy follows from the subtraction, not from fashion.
Mapping Objectives to Architecture
Mapping Objectives to Architecture
| Objective shape | Architecture that meets it |
|---|---|
| RTO hours, RPO hours | Backup/restore with cross-region copies |
| RTO < 1h, RPO minutes | Pilot light with replication + scripted promote |
| RTO minutes, RPO seconds | Warm standby, scaled up on failover |
| RTO near zero, RPO near zero | Active/active with multi-region data layer |
Cost rises as you move down the table — idle standby capacity, duplicate data planes, and dual-write complexity. Assign tiers per application (gold/silver/bronze) rather than one org-wide pair; a blog and a payments ledger do not deserve the same budget. Write both numbers into each service's runbook header so on-call knows the clock that matters at 3 a.m.
Pitfalls and Interview Focus
Pitfalls and Interview Focus
RTO includes detection, decision, and validation — not just the deploy script. Teams that measure only "promote took four minutes" discover in an incident that nobody noticed for twenty. RPO applies to committed transactions: replicated-but-not-durable writes and in-flight sessions still count as lost.
Other traps: averaging RTO across a distribution hides the tail that hurts; DR scope that forgets DNS, certificates, and configuration stores; and stale numbers — architecture changes but objectives never get revisited.
Interview: state objectives first, pick the strategy whose measured characteristics fit, then defend the cost. "We chose backup/restore because the stated RTO is four hours" is a strong, complete answer.
Quiz
1. An app can tolerate 15 minutes of downtime but nothing older than 30 seconds of data. Which pair?
2. Which architecture naturally meets an RPO of seconds?
3. What is commonly forgotten when calculating real RTO?
Flashcards
Question
RTO
Click to reveal answer
Answer
Max tolerable downtime — includes detection, decision, and validation, not just execution.
Question
RPO
Click to reveal answer
Answer
Max tolerable data loss, measured as the age of the newest usable copy.
Question
Objective → strategy
Click to reveal answer
Answer
Hours/backup-shaped → backup-restore; minutes+replication → pilot/warm; near-zero → active/active.
Question
Tiering
Click to reveal answer
Answer
Per-application gold/silver/bronze objectives instead of one org-wide pair.
Question
Validation
Click to reveal answer
Answer
Game days measure true RTO/RPO; stale numbers drift below reality.
Revision Notes
Key Takeaways
- 1. RTO = downtime budget, RPO = data-loss budget
- 2. Objectives pick the architecture; architecture sets the bill
- 3. Measure the whole failure timeline, not just the promote step
Interview Tips
- • Lead with the two numbers, then derive the strategy — never start with a service name
- • Show cost awareness: name what each lower row of the DR table adds to the bill
Cheat Sheet
RTO=downtime budget (detect+decide+execute); RPO=data-loss age. Hours→backup/restore; minutes→pilot light/warm standby; near-zero→active/active. Tier per app; verify with game days.