What are RPO and RTO and why do they matter?
RPO and RTO are the two fundamental metrics that define a system's disaster recovery requirements. They are not technical metrics — they are business requirements that translate into technical architecture decisions.
**Recovery Point Objective (RPO)** is the maximum acceptable amount of data loss measured in time. If your RPO is 1 hour, your recovery strategy must ensure you can restore the system to a state no older than 1 hour ago. RPO is determined by asking: "If we lost all data after a certain point, how much data loss can the business tolerate?" A payment processor might have RPO = 0 (zero data loss). A blog might accept RPO = 24 hours.
**Recovery Time Objective (RTO)** is the maximum acceptable downtime — the time from a failure event to full service restoration. If your RTO is 4 hours, you must be able to detect the failure, execute recovery, and restore normal service within 4 hours. RTO is determined by asking: "How long can the business operate without this system?" An e-commerce site during Black Friday might have RTO = 5 minutes. An internal analytics dashboard might have RTO = 24 hours.
These two metrics drive different technical investments:
- **Backup frequency**: To achieve RPO = 1h, you need backups every hour at minimum. Continuous WAL archiving (point-in-time recovery) approaches RPO = seconds. - **Replication**: Synchronous replication achieves RPO = 0 but adds write latency. Asynchronous replication improves write performance at the cost of RPO > 0. - **Hot standby vs. cold standby**: A hot standby (fully replicated, running) achieves RTO in seconds/minutes. A cold standby (restore from backup) might take hours — fine for RTO = 4h, not for RTO = 15min. - **Multi-AZ vs. multi-region**: Multi-AZ addresses data-center failures with low RTO/RPO. Multi-region addresses regional outages at the cost of higher replication lag (higher RPO) and more complex failover.
A common mistake is conflating RPO and RTO or designing infrastructure without explicit targets. Organizations should establish RPO/RTO per service tier, test recovery procedures regularly, and document the gap between target and actual achieved metrics. Having a 4-hour RTO target but a recovery procedure that actually takes 8 hours is a liability.
Correctly defines both RPO and RTO with clear examples, explains that they are business requirements not technical ones, and names at least two architectural implications for each.
Explains the RPO/RTO trade-off curve (lower RPO/RTO = higher cost), distinguishes synchronous vs. async replication impact on RPO, covers hot vs. cold standby for RTO, and mentions the importance of testing recovery procedures.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment