A stakeholder asks for zero RPO across the estate. What does that cost and what would you propose instead?
Show the full answer Hide the answer
What is being tested
Whether you can translate a business ask into its architectural price and then negotiate with a better-shaped proposal rather than a refusal.
What zero RPO actually requires
Zero data loss means a write is not acknowledged until it is durable in a second location. Synchronous replication. The consequences follow directly:
- The network round trip is inside every write. Same-region, that is a few milliseconds. Cross-region, it is tens to hundreds — often a 10x or worse increase in write latency.
- Availability can decrease. If the remote replica is unreachable, writes block, unless the quorum configuration is set to tolerate its absence — at which point you no longer have zero RPO. This surprises people: the mechanism bought to improve resilience can make the system less available.
- Cost roughly doubles for the replicated tier, plus inter-region transfer.
- Every asynchronous path must also be covered. Zero RPO for the database and a message queue that loses in-flight messages is not zero RPO for the business.
An RPO of zero is qualitatively different from an RPO of one second, and the difference in price is much larger than the difference in the number.
What to propose instead
Per-service RPO, derived from consequence. Do not ask "how much data loss is acceptable" — the answer is always zero. Ask:
- What is the consequence of losing the last five minutes of this data?
- Can it be reconstructed from another source? A payment often cannot; a recommendation event usually can; an analytics event certainly can.
- Is there a regulatory or contractual floor?
That conversation produces a differentiated answer, and the differentiation is where the money is:
| Data | RPO | Mechanism |
|---|---|---|
| Payment and ledger records | Near zero | Synchronous replication, accepted latency cost |
| Order state | Seconds | Continuous asynchronous replication |
| User profile | Minutes | Asynchronous replication |
| Analytics events | Hours | Replayable from source, or acceptable loss |
| Derived caches and indexes | Any | Rebuildable |
The cheaper way to get most of the value
For many systems the honest goal is not zero loss but no unrecoverable loss. A durable append-only log at the edge of the system, replicated, means that even if a downstream store loses the last thirty seconds, the events can be replayed. That is dramatically cheaper than synchronous replication of every store and satisfies the actual business requirement, which is almost always "we must not lose a customer's transaction" rather than "no byte may ever be lost".
The related point about RTO
RTO is not the failover time. It is detection plus decision plus execution plus verification. A failover that technically takes 90 seconds inside a 15-minute RTO leaves 13 minutes for someone to notice, decide and get permission — and that is where the time actually goes. Measuring RTO in a rehearsal, from the moment of injection rather than the button press, is what makes the number real.