Requirements capture: RPO, RTO, workloads

Why this matters in production

Most infrastructure problems do not start with hardware. They start with a vague requirement that an architect interpreted optimistically and an operator inherited. RPO and RTO are the two most important numbers in any design conversation; getting them wrong is the most common way an infrastructure team buys the wrong equipment.

Mental model

Three questions frame the entire design:

1. How much data can we afford to lose? (RPO — Recovery Point Objective)
2. How long can we afford to be down? (RTO — Recovery Time Objective)
3. What workloads do we run, and how do they depend on each other?

The third is usually the hardest, because dependencies are often undocumented. A database that “needs 1 hour RTO” is meaningless if the application that talks to it takes 4 hours to restore from source.

flowchart LR
  BUS[Business requirement] --> RPO[RPO target]
  BUS --> RTO[RTO target]
  RPO --> BCK[Backup frequency, replication interval]
  RTO --> RUN[Runbook complexity, hot spares]
  WL[Workload inventory] --> CAP[Capacity model]
  WL --> DEP[Dependency map]
  DEP --> RUN

Defining RPO and RTO

RPO (Recovery Point Objective) is the maximum amount of data the business is willing to lose, expressed as time. RPO = 15 minutes means at most 15 minutes of data may be lost in any disaster. This translates to:

• Backups at least every 15 minutes (or replication interval ≤ 15 minutes).
• A backup or replication target that captures at least that cadence.

RTO (Recovery Time Objective) is the maximum acceptable downtime after a disaster. RTO = 1 hour means the workload must be back in production within 60 minutes of an incident.

These are business targets. They are set by the business owner, not by the infrastructure team. The infrastructure team’s job is to translate them into technology.

Availability tiers

Most environments group workloads into a small number of tiers. A typical classification:

The workload inventory

Before sizing anything, build a spreadsheet of every workload. Columns:

This list is the input to the capacity planner (covered in §II.5). Without it, capacity planning is fiction.

Compliance and security requirements

Common requirements that change the design:

• PCI-DSS: segmented network, audited access, encrypted backups, MFA for admin.
• HIPAA: encrypted at rest, audit logging, access control, BAA with the hosting provider (rare for on-prem).
• GDPR: data residency (which country the storage must live in), data subject access procedures, breach notification timelines.
• SOC 2: change management, monitoring, access reviews, incident response runbooks.
• FIPS 140-3: validated cryptography for sensitive workloads (relevant for US public sector).

Each of these may force a specific design choice. PCI-DSS may require the backup network to be isolated from the production network. SOC 2 may require every admin action to be logged with a user identity. HIPAA may force encryption-at-rest with a particular key-management approach.

Hands-on lab (Mode C)

Build a workload inventory for a fictional business. Suggested scope:

• 1 critical database (PostgreSQL, 8 vCPU, 32 GB RAM, 10k IOPS, Tier 0)
• 2 web application servers (Linux, 4 vCPU, 8 GB, Tier 1)
• 1 identity provider (Active Directory, Tier 0)
• 1 file server (Windows, Tier 1)
• 3 internal tools (Tier 2)
• 1 development cluster (Tier 3)

For each, write down: RPO target, RTO target, owner, and any compliance scope. Discuss with peers whether the targets are realistic.

Production considerations

Common mistakes

• Treating RPO and RTO as synonymous. They are different axes.
• Letting the design drive the requirement. The business sets the target; the design meets it (or fails to).
• Skipping the workload inventory. Without it, sizing is guesswork.

Key takeaways

• RPO = how much data you can lose; RTO = how long you can be down.
• Per-workload tiers, not cluster-wide targets.
• Compliance and security requirements constrain the design before any technology is chosen.

Knowledge check