City leadership states that losing the last hour of 311 tickets after failover is unacceptable. How should that statement drive architecture?
Select an answer to reveal the explanation.
Short Explanation
“Don’t lose the last hour of 311 tickets” is plain-English RPO. Build replication or backups that can’t lag more than that. Pretending RPO is a warranty term—or planning on weekly loss—misses what leadership said.
Full Explanation
When city leadership states that losing the last hour of 311 tickets after failover is unacceptable, architects must treat that as an RPO of under one hour and design replication or backup frequency to keep potential data loss inside that window. Business language about “losing the last hour” is an RPO statement even if executives never say the acronym. Architecture choices—continuous replication, sub-hour snapshots, or streaming—must be justified against that hour bound for the 311 platform.
Ignoring the statement because RPO “only applies to hardware warranties” misunderstands disaster recovery vocabulary used in public-sector architecture reviews. Setting RPO to one week and relying on citizen callbacks to recreate tickets rejects the leadership constraint and harms service trust. Defining only RTO and assuming backups every 24 hours are always enough leaves a full day of ticket loss, which violates the hour requirement.
Exam caveat: translate stakeholder sentences into RTO and RPO numbers before picking DR patterns; “cannot lose more than X” is RPO, “must be back in Y” is RTO. Operational check: write RPO under one hour into the 311 DR plan, measure actual replication lag, run a failover drill, quantify tickets lost, and adjust until loss stays inside the hour with alerting on lag.