RTO & RPO
Also known as: Recovery Time Objective · Recovery Point Objective
Recovery Time Objective (RTO) is how long the business can tolerate the system being down before money is at stake. Recovery Point Objective (RPO) is how much data the business can tolerate losing. The pair is the input to the disaster-recovery design — backups, replicas, failover automation, restore drills. Without an explicit RTO/RPO every architectural choice that touches recoverability is implicit and untestable.
Concepts that travel with this one.
Architecture rarely lives in isolation — these are the terms that come up in the same conversation.
SLO & Error Budget
A Service Level Objective is the explicit reliability target a service commits to — say, 99.9% successful requests measured over 30 days. The complement (0.1%) is the error budget: the operationally-permitted failure for the period. When the budget is healthy, the team ships features; when it is exhausted, ship velocity stops until reliability is restored. This is the contract that turns 'reliability' from a feeling into a number.
Blue-Green Deployment
Blue-green deployment runs two identical production environments side by side. The live environment (blue) serves traffic while the new version (green) is deployed and warmed in parallel. Cutover is a load-balancer flip, and rollback is the same flip in reverse. The cost is double the compute during the window; the benefit is a zero-downtime, instantly-reversible release path.
Building a system where RTO & RPO is the load-bearing decision?
30 minutes on the phone, one page in your inbox — what to build, what to skip, what it will cost. You keep the audit even if we are not the right fit.