A hybrid city ops app must keep Webex ChatOps usable when the on-premises controller is unreachable, and keep inventory usable when a SaaS Cisco API is down. What HA design property does that require?

High availability for a hybrid city ops app that mixes on-prem controller hops and SaaS Cisco APIs requires independent failure domains. Webex ChatOps must degrade gracefully when the on-premises controller is unreachable, and inventory must remain usable when a SaaS API is down. Separate timeouts, circuits, caches, and UI panels keep one outage from blacking out the other capability.

Treating on-prem and SaaS hops as a single local call in one process fails because both share one fate—any remote failure fails the combined operation. A shared in-process lock that blocks ChatOps until every controller answers fails by turning partial outage into total stall. Collapsing both integrations into one synchronous function for simpler tracing fails because simpler stack traces are bought by coupling availability.

Exam caveat: independent domains still need clear degraded UX and correlation IDs; isolation without observability just produces quieter, harder-to-diagnose partial failures.

Operational check: block the on-prem controller path in a test environment and confirm ChatOps paths that do not need it still succeed, then reverse the test for the SaaS inventory hop.

Implement independence with per-hop timeouts, bulkheads or separate thread pools, and UI panels that tolerate missing data. Hybrid city ops especially needs this because on-prem WAN cuts and SaaS regional events rarely coincide. HA is not one big try/except around every Cisco call; it is containing blast radius so ChatOps and inventory fail on their own clocks.