We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Reliability & Resilience
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers RPO across a run of lessons, not one page. These 4 alone are about 130 minutes of step-by-step reading, every one with a quiz.
Recovery Point Objective, how much data loss is acceptable in a disaster.
Cross-region (cross data center) replication explained: sync vs async, replication lag, RPO and RTO, failover loss, and what AWS, Spanner and CockroachDB do.
Capture every change in real-time. WAL streaming for near-zero RPO.
How a replica is promoted to primary when a database fails, step by step. Covers RPO vs RTO, split brain, fencing, and the 2018 GitHub outage.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with RPOpay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The industry examples in “The next question”:
Cross-Region Replication: Sync vs Async, Lag, RPO and the Speed of Light
Cross-region (cross data center) replication explained: sync vs async, replication lag, RPO and RTO, failover loss, and what AWS, Spanner and CockroachDB do.
Continuous Backup
Capture every change in real-time. WAL streaming for near-zero RPO
Database Failover
How a replica is promoted to primary when a database fails, step by step. Covers RPO vs RTO, split brain, fencing, and the 2018 GitHub outage.
Connection Draining
Removing an instance on purpose, the race between the pool update and the shutdown, and what in-flight leaves out
Timeouts and Fallbacks: What Should a Service Return When Its Lookup Is Slow?
I made the lookup behind a prediction service slow on purpose: 1 lookup in 100 froze for 1 to 2 seconds. Then I tried 21 ways to cope, 5 times each, on a small rented computer with one processor core. With no time limit, the slowest 1 in 100 answers took about 1 second. A 25-thousandths-of-a-second limit (25 ms) with a ready-made backup score brought that down to 26 ms, and about 1.6 answers in 100 were backups. Using the customer's score from last month as the backup hurt the ranking so little I could not measure it. One shared time limit for the whole request kept most of the slowest answers under 25 ms. At 300 requests a second, trying again rescued every frozen lookup. At 450 a second, trying again flooded the store in 3 of 5 runs (94%, 84% and 60% backups), and waiting a random moment first did not help. Every step on the rented computer is recorded, so you can build it yourself.
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.
This page explains the idea. The "RPO" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the RPO lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about RPO in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
