RPO
Recovery Point Objective: the maximum acceptable amount of data loss measured in time. An RPO of 1 hour means you can afford to lose up to 1 hour of data.
What is RPO?
In short
RPO (Recovery Point Objective) is the maximum amount of data, measured in time, that a system can afford to lose during a failure. An RPO of one hour means that after a disaster you accept losing up to the last hour of writes, so your backups or replicas must be no more than an hour behind.
What RPO actually measures
RPO answers one question: if everything goes down right now, how far back in time is the last copy of my data that I can recover? It is expressed as a duration, not a percentage. An RPO of 5 minutes means you can lose at most 5 minutes of writes. An RPO of zero means you can lose nothing, every committed transaction must survive.
The number is a business decision, not a technical one. A bank's payment ledger might demand an RPO of zero because losing a single transfer is unacceptable. A blog's analytics table might tolerate an RPO of 24 hours because losing a day of pageview counts costs nothing. You pick the RPO first, then build the data-protection scheme that meets it.
RPO is the partner of RTO (Recovery Time Objective). RPO is about how much data you lose; RTO is about how long you are down. The two are separate dials. You can have a 5-second RPO but a 4-hour RTO, meaning you lose almost no data but it takes 4 hours to bring the service back online.
How you hit a target RPO under the hood
Your RPO is set by the gap between your data and its most recent durable copy. Take backups every 24 hours and your worst case loses 24 hours of changes, so your RPO is 24 hours. Shrink the RPO by copying data more often.
Three mechanisms cover the range. Periodic backups (a nightly dump to S3) give RPOs measured in hours. Continuous log shipping, where the database streams its write-ahead log to another location every few seconds, gives RPOs of seconds to a minute. Synchronous replication, where a write is not acknowledged to the client until a second node has it on disk, gives an RPO of zero because no acknowledged write can be lost.
There is a cost ladder. Synchronous replication across regions adds tens of milliseconds to every write because the primary waits for the remote node. Asynchronous replication is fast but leaves a small window of in-flight data that can vanish if the primary dies before the replica catches up. That replication lag is, in practice, your RPO.
Choosing a target and the trade-offs
Tighter RPO costs more money and more latency. Going from a 1-hour RPO to a 1-second RPO might mean moving from nightly snapshots to a multi-node synchronous cluster, which can multiply your infrastructure bill and slow down every write. So you tier your data: critical tables get near-zero RPO, derived or rebuildable data gets a relaxed RPO.
A common mistake is setting one RPO for the whole system. Order records, user accounts, and audit logs each deserve a different RPO. Another mistake is writing an RPO into a contract and never testing it. An RPO is only real if you have actually restored from a backup and measured how far behind it was.
Watch for the gap between your stated RPO and your real one. If you claim a 15-minute RPO but your replication lag spikes to 40 minutes under load, your true RPO is 40 minutes at the worst moment. Monitor replication lag and backup age as live metrics, and alert when they exceed the RPO you promised.
A concrete example
Picture an e-commerce checkout running on PostgreSQL. The team sets two RPO tiers. The orders and payments tables get a near-zero RPO using synchronous streaming replication to a standby in a second availability zone, so a committed purchase can never be lost even if the primary instance fails.
The product catalog and recommendation data get a 6-hour RPO, served by snapshots taken every 6 hours, because that data can be rebuilt from upstream sources and losing a few hours of it does not harm a customer. This split keeps the expensive zero-RPO machinery on the data that truly needs it.
When the primary instance crashes, the standby is promoted. Because orders were synchronously replicated, no purchase is lost (RPO met). The catalog may roll back up to 6 hours, which is acceptable and within its declared RPO. The team verifies this quarterly by killing the primary in a game day and checking how much data the standby was missing at failover time.
Where it is used in production
Amazon RDS and Aurora
Multi-AZ synchronous replication gives a near-zero RPO, and point-in-time recovery lets you restore to any second within the backup retention window.
PostgreSQL
Write-ahead log streaming to a hot standby reduces RPO to seconds, and synchronous_commit set to remote_apply gives a true zero-data-loss RPO.
Apache Kafka
Setting acks=all with a minimum in-sync replica count means a produced message is not acknowledged until it is on multiple brokers, driving the RPO toward zero for the event log.
MongoDB
Replica sets with a write concern of majority ensure acknowledged writes survive a primary failure, keeping the practical RPO at zero for critical collections.
Frequently asked questions
- What is the difference between RPO and RTO?
- RPO measures how much data you can lose, expressed as a time window like 5 minutes of writes. RTO measures how long the service can be down before it must be back, like 30 minutes of downtime. RPO is about data freshness at recovery; RTO is about speed of recovery. They are tuned independently.
- Can RPO ever be zero?
- Yes, but only with synchronous replication, where a write is acknowledged to the client only after a second node has durably stored it. That guarantees no committed write is lost, at the cost of added write latency. Asynchronous schemes always leave a small loss window equal to the replication lag.
- How do I calculate my current RPO?
- It equals the maximum gap between your live data and its most recent durable copy. With nightly backups the worst case is about 24 hours. With log streaming it is your replication lag, often a few seconds. Measure it by restoring from your actual backup or failing over to a replica and checking how much data was missing.
- Does a lower RPO always cost more?
- Generally yes. Moving from hourly backups to second-level synchronous replication adds infrastructure (extra nodes, cross-zone bandwidth) and write latency. The usual answer is to tier data so only the most critical tables carry a near-zero RPO while rebuildable data uses a relaxed one.
- Is RPO the same as backup frequency?
- Backup frequency sets the upper bound on RPO but does not equal it. If you back up every hour, your RPO can be no better than one hour, and it could be worse if a backup fails or replication falls behind. RPO is the real worst-case data loss you can tolerate; backup frequency is just one lever that influences it.
Learn RPO hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on RPO as part of a larger topic.
See also
Related glossary terms you might want to look up next.
RTO
Recovery Time Objective: the maximum acceptable downtime after a disaster. An RTO of 15 minutes means the system must be back online within 15 minutes of failure.
Disaster Recovery
A plan and set of procedures for restoring systems after a catastrophic failure. Defined by RPO (how much data you can lose) and RTO (how long you can be down).
Replication
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.
Chaos Engineering
Deliberately injecting failures into a system to test its resilience. Netflix's Chaos Monkey randomly kills servers to ensure the system survives.
Back Pressure
A flow control mechanism where a slow consumer signals upstream producers to slow down. Prevents systems from being overwhelmed by data they can't process.
SLI
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.