Episode 47 — Availability Requirements: turning uptime promises into architecture
Availability requirements appear throughout CloudNetX scenarios as the driver that determines whether a design can tolerate component failure, site loss, or maintenance disruption, and this episode explains how to translate uptime promises into concrete architectural decisions. It defines availability as the expectation that a service remains usable when needed, and it introduces the idea that availability is built from dependencies, not from a single “high availability feature.” The first paragraph focuses on turning business language into technical targets by identifying acceptable downtime windows, criticality tiers, and recovery needs that shape the architecture. It explains how failure domains—device, link, power, zone, region, provider—must be identified explicitly, because availability design is essentially the art of preventing one failure domain from collapsing the whole service. It also clarifies the difference between avoiding outages and recovering from them, because many scenarios hinge on whether the requirement is continuous operation or acceptable interruption with a defined recovery.
