RPO & RTO

RPO — Recovery Point Objective — is how much data you can afford to lose, measured backwards in time from the disaster. An RPO of one hour means that after recovery, up to one hour of the most recent writes may be gone, and the business has agreed that this is survivable. RPO is determined almost entirely by how often you take an independent copy: hourly backups give an RPO of roughly one hour, continuous replication gives seconds, and synchronous replication gives zero at the cost of write latency.

RTO — Recovery Time Objective — is how long you can afford to be down, measured forwards from the disaster. An RTO of four hours means the service must be serving again within four hours of the event starting — including detection, decision, restore and verification, not just the part where someone types commands. RTO is determined by how much infrastructure is already running and how automated the recovery is.

They are independent. A system can have an RPO of five seconds and an RTO of eight hours: continuous replication means almost nothing is lost, and a manual rebuild means it takes all day to serve again. The reverse also exists: a hot standby with nightly backups recovers in minutes and can lose a day of data if the failure was corruption rather than infrastructure. Confusing the two produces designs that solve the wrong half — and the half that was left unsolved is discovered during the incident.

The productive direction is: the business states what an hour of downtime and an hour of lost data cost, engineering states what each tier costs, and the two are compared. The unproductive direction — overwhelmingly the more common one — is that an architecture is built first and its RPO and RTO are measured afterwards and written into a document as though they had been requirements.

Make the conversation concrete with scenarios rather than adjectives. *"The payment ledger loses fifteen minutes of transactions. What happens?"* — for a payments business the answer involves reconciliation with an external provider, customer disputes and possibly a regulator, so the RPO must be seconds. *"The recommendation cache is empty for six hours."* — recommendations are worse, nothing is lost permanently, and the RPO is effectively infinite because the data is derived. Same company, same disaster, requirements three orders of magnitude apart.

That last observation is the reason to tier by data set rather than by system. Uniform requirements across an estate are always wrong in one of two directions: either you are paying mission-critical prices for logs and derived data, or you are protecting the payment ledger the same way you protect an analytics cache. Tiering is what makes the total affordable.

Moving from a 24-hour RPO to a one-hour RPO is usually cheap: take backups more often. Moving from one hour to one minute means continuous log shipping and the infrastructure to receive it. Moving from one minute to zero means synchronous replication, which adds the replication round trip to every single write — a latency tax paid on every transaction forever, in exchange for a guarantee that matters during an event that may never occur.

RTO has the same shape. Hours are cheap: restore from backup into an environment you build when needed. Tens of minutes need a pilot light. Minutes need a warm standby. Sub-minute needs active-active and the organization to run it. Each step multiplies both money and operational burden, and the last step multiplies engineering complexity most of all.

The most valuable thing this framing produces is permission to say no. When a stakeholder asks for zero data loss and instant recovery, the answer is not "no" but "here is what that costs, and here is what a fifteen-minute RTO costs instead" — a factor of ten or more in the total. Presented as a price rather than a technical objection, the requirement usually relaxes on its own.