During a WAN blip between regions, a public city status page should keep answering rather than go dark, even if some counts are briefly stale. Which CAP-oriented choice fits best?

A public city status page that must keep answering during a WAN blip is choosing availability under partition: serve reachable data even if some counts are briefly stale rather than go dark for residents and first responders. That CAP-oriented preference accepts temporary divergence as the cost of continued service. Refusing all reads until every replica proves identical totals prioritizes strong consistency and can blank the page exactly when citizens need updates. Shutting the status page until the WAN recovers is an extreme availability failure and abandons the civic communications mission during incidents. Deleting partitioned replicas so only one region remains forever removes redundancy and turns a temporary partition into a permanent single-site risk. Exam caveat: availability-first is appropriate for informational dashboards with stale-tolerant metrics; it is the wrong default for ballot totals or fund-transfer confirmation. Operational check: during a controlled regional disconnect, confirm the status page still returns HTTP success with a visible freshness indicator, and that stale counters reconverge automatically after the link returns. In production terms for availability-first public status pages, assign an owning team, wire a dashboard that shows the pattern is healthy under peak civic load, and require a staging drill that rehearses failure and recovery before resident impact. Revisit the choice when traffic shape, retention, or integrity needs change, and keep a named rollback owner on the change record. Re-test both the happy path and the failure path for availability-first public status pages after material dependency upgrades so regressions are caught before the next public release.