A city’s online building-permit system must keep issuing permits if the primary processing site fails. Leadership wants failover across sites with enough capacity. Which approach best meets that need?

Resilient multi-site processing for a city’s online building-permit system requires more than a second address on a slide: the alternate site must have agreed capacity—compute, storage, licensing, staffing support, and network bandwidth—to absorb critical permit workload when the primary processing site fails. Capacity agreements (internal reservations or contractual cloud/colocation commitments) turn geographic diversity into usable failover. Without them, failover becomes a race to acquire resources after citizens already cannot submit permits.

Keeping a single site while merely lowering the RTO on paper creates a false recovery target with no place to run. Failing over only DNS while leaving compute and database capacity exclusively at the primary campus points users at an empty destination; name resolution is not workload capacity. Using a cold warehouse with no capacity agreement and hoping to purchase hardware after an outage may eventually work for noncritical systems, but it cannot reliably meet continuous permit issuance when supply chains and imaging take days.

Exam caveat: alternate processing sites succeed when recovery capacity is pre-arranged. Distinguish site types (hot/warm/cold) from the separate requirement that whatever site you choose can actually carry the load. Paper metrics without resources are a common distractor pattern.

Operational check: validate failover with a test that processes a representative permit workload at the alternate site, confirm capacity contracts and licensing cover peak municipal demand, and document who authorizes site activation so DNS, apps, and databases move together.