Composite Availability

Composite availability describes whether an entire application or business operation is usable, rather than whether an individual component is running. Begin by defining success from the user's perspective: for example, a checkout request must complete correctly within two seconds. Then identify the dependencies required for that operation, including traffic routing, application compute, authentication, databases, and external payment systems. Different operations can have different availability because they follow different dependency paths.

When every component in a path must work, those components form a series dependency. Under an assumption of independent availability events, the composite availability is the product of their individual availabilities: A = A1 × A2 × ... × An. For example, three required tiers, each with an assumed availability of 99.9%, produce 0.999³, or approximately 99.7003%. Over a 30-day month, that corresponds to approximately 129.5 minutes of unavailability, compared with 43.2 minutes for a 99.9% target. These are modeling examples, not published service commitments.

Redundancy changes the calculation when any one of several alternatives can satisfy the operation. For independent alternatives, availability is A = 1 − ((1 − A1) × (1 − A2) × ... × (1 − An)). Two independent alternatives, each available 99.9% of the time, yield a theoretical 99.9999%. This assumes either alternative can serve the workload successfully and that detection, routing, failover, and state requirements do not introduce additional failures. A redundant application tier may improve substantially while the overall application remains constrained by a required database or identity provider.

Real cloud failures are not always independent. Instances in the same Availability Zone can share infrastructure risks, while instances in different zones can still share a faulty deployment, exhausted quota, credential problem, or regional dependency. The probability formulas are useful architectural models, not guarantees. Explicitly model shared dependencies and common-cause failures rather than applying the parallel formula to replicas that fail together.

Apply the concept by distributing application capacity across failure domains, using health-aware routing, and ensuring surviving capacity can handle expected traffic. For a database-dependent application, evaluate database failover time, connection recovery, and transaction retry behavior. A standby that requires promotion is not equivalent to an immediately usable independent replica. Test failure scenarios to measure the user-visible interruption rather than assuming that redundancy eliminates downtime.

Reducing mandatory dependencies can also improve availability. An order service might commit an order and queue a notification instead of requiring the email system to respond before checkout succeeds. This improves the checkout dependency path, but it introduces eventual processing and requires durable queuing, idempotency, and backlog monitoring. Graceful degradation is valid only when the reduced behavior still meets the defined business requirement.

For SLA questions, distinguish a contractual service-level agreement from an internal service-level objective and a measured service-level indicator. A provider SLA defines its own scope, measurement method, exclusions, and remedies; multiplying advertised SLA percentages does not create a contractual application guarantee. Assess the assumptions stated in an exam scenario, calculate series or parallel availability where appropriate, and compare the result with the business target. In production, validate the model with end-to-end measurements, incident history, and failover tests, balancing greater redundancy against cost and operational complexity.