How do you decide what recovery point and recovery time objectives a given database should have, when every tightening of those numbers costs money and adds write latency or operational complexity? Walk through how you would tier a portfolio of databases.

## The numbers are business inputs, not engineering outputs Engineers cannot choose a recovery point objective, because the objective is a statement about acceptable loss - a business risk position. The engineering job is to (a) elicit the impact, (b) price the architectures that meet candidate targets, and (c) make the trade-off visible enough that a decision gets made deliberately rather than by default. The questions that actually generate the numbers: - **What does downtime cost per unit time?** Sometimes it is linear (lost transactions per minute), sometimes it is a step function (a market close, a regulatory reporting deadline, a nightly batch window that cannot slip), and sometimes it is non-financial (safety, patient care, contractual penalties). - **What does lost data cost?** Crucially, *is it reconstructible?* If clients retry idempotently, if an event bus retains the last day, or if the upstream system can replay, then losing five minutes of database writes costs a replay job, not the data. Reconstructibility is the single biggest lever on recovery-point cost. - **What is the failure frequency you are protecting against?** Paying a permanent per-commit latency tax on every transaction to protect against an event with a multi-year return period is a real trade, not an obvious one. - **What are the external obligations?** Regulatory rules, contractual service levels, and insurance requirements sometimes set floors regardless of internal economics. ## Costs of tightening, stated plainly - Tightening the **recovery point** toward zero means synchronous commit - a network round trip on every write, which is sub-millisecond within a zone and tens of milliseconds across regions. That tax lands on all traffic all the time. It also couples availability to the standby: strict synchronous means the primary blocks when the standby is unreachable, so a zero-loss guarantee can *reduce* uptime. - Tightening the **recovery time** means running warm standby capacity that is idle for its purpose (mitigated by serving reads), automated failover with a quorum coordinator, and the operational maturity to be safe about fencing. Automation itself carries risk: a spurious failover is an outage you caused. - Both mean more environments, more drills, more runbooks, more on-call surface, and more people who must understand the topology. Complexity is a recurring cost paid in incidents caused by the disaster-recovery machinery itself. ## Tiering the portfolio Bespoke targets per database do not scale - they cannot be staffed, tested, or budgeted. Define a small number of tiers, each a **pre-engineered, drilled, priced** package: | Tier | Recovery point | Recovery time | Architecture | Relative cost | |---|---|---|---|---| | 1 | ~0 | minutes | synchronous cross-zone commit, async cross-region standby, automated failover, proxy-based repointing | highest, plus write latency | | 2 | seconds | tens of minutes | async standby, continuous archiving, semi-automated failover | moderate | | 3 | minutes | hours | backups plus archiving, restore-based recovery | low | | 4 | hours-days | hours-days | periodic backups; primary path is rebuild from upstream | minimal | Governance that makes tiers work: every data store has a named business owner; the owner selects a tier and the cost is charged to them; each tier has a mandatory drill cadence and a published measured-versus-declared record; a store with no tier defaults to the cheapest, which is what actually forces owners to engage. ## Cross-store consistency A subtlety that separates strong candidates: recovery objectives apply per data store, but a business transaction usually spans several. A tier-1 database recovered to the failure instant alongside a tier-3 object store recovered to six hours earlier produces rows pointing at files that do not exist. So tiering must be applied to a **business capability**, not to isolated databases, and the recovery plan needs a reconciliation step - or the capability's weakest store defines its real objective. ## Reduce the requirement before you buy it The cheapest way to meet a hard recovery point is often to need less of it: - **Idempotent, retryable writes** with client-side or gateway-side buffering mean a few minutes of lost database writes are replayed rather than lost. - **An event log upstream** with retention longer than the worst recovery point turns data loss into a replay job. - **Degraded-mode operation** - read-only serving from a replica, or queueing writes at the edge - converts a hard outage into partial service and relaxes the recovery-time requirement dramatically. Proposing these before proposing cross-region synchronous replication is the mark of someone who has actually paid for the latter. ## Closing the loop Whatever is chosen must be measured and reported: drill results per tier, measured versus declared, and a forecast of when growth will breach a tier's promise. When the measurement crosses the promise, the choice is explicit - fund the next tier or restate the objective. Carrying an undeclared gap is the failure mode that turns a bad day into a company-defining one.