Emergency dispatch case stores must recover within minutes, while a best-effort monthly park-usage dashboard can tolerate longer outages. How should resilience be designed?
Select an answer to reveal the explanation.
Short Explanation
Not every toaster needs a nuclear bunker. Match DR tiers to how badly the city hurts when that store is down—dispatch is not the same as a nice-to-have park chart.
Full Explanation
Resilience architecture for civic data stores must align recovery objectives with business and data criticality. Emergency dispatch case stores that must recover within minutes need tighter RTO/RPO, tested failover, and funded multi-site or equivalent protections, whereas a best-effort monthly park-usage dashboard can tolerate softer tiers. Explicit resilience tiers make those trade-offs visible to budget owners and prevent both uniform over-engineering and dangerous under-protection. Applying identical multi-site failover to every store regardless of criticality wastes scarce funds and staff attention that should protect life-safety and core service systems. Skipping disaster recovery because cloud vendors promise perfect uptime confuses shared-responsibility marketing with architecture assurance; municipal teams still own recovery design, backups, and restore testing. Protecting only marketing websites while leaving citizen-safety systems on a single undeclared server inverts priorities and creates unacceptable public-risk exposure. Exam caveat: tiering is not permission to leave important systems unprotected; best-effort analytics still need defined backups and restore paths, just not the same RTO as dispatch. Operational check: classify each store by citizen-impact criticality, assign RTO/RPO and failover pattern, fund the critical tier first, and schedule restore tests with evidence retained in the municipal runbook.