Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Quality attributeChapter I · Requirements · Building block 4 of 6

Availability

Availability describes whether a clearly named function can be used successfully at a given time. Every statement therefore needs a function, a period of time and a success criterion.

By Michael Meierhoff · Meierhoff Systems

  1. FunctionAvailability is per function.
  2. PeriodA statement applies to a time window.
  3. TargetThe goal determines how much failure is allowed.

Context

Why this is important

Availability is per function, not for “the system”. It results from the failure frequency (MTBF) and the recovery time (MTTR): it increases in frequency or shorter. How quickly a service returns is treated recovery.

Here you set and measure whether a function is usable. How the architecture achieves this is shown by the tactics below; objectives in operation control SLIs, SLOs & Error Budgets.

At a glance · Availability per function and period

Function, period and success criterion form a statement whose target sets the permitted downtime.
Shop example · Playing through scenarios

Two functions, one fault

The shop can accept an order with the status clarification running, while the external payment provider temporarily does not reply. The order acceptance thus remains usable; the payment authorization is disturbed during this period.

This is how you read the picture

  1. Function Order acceptance and payment authorization tiles show different states in the case of the same fault.
  2. Period Switches 10:00, 10:04, 10:12; in the regulator "per month" and "per year".
  3. Target Control “What do the nines mean?” translates percent into allowed minutes of downtime.
Payment provider
  • runningOrder acceptanceaccepts orders
  • runningPayment authorisationAuthorised payments
  • runningOrder B-1042is paid

2 from 2Useful functions

In normal operation, both functions can be used. The statement is valid for each function and time period.

Values illustrative

Switch the payment provider. As you can see: Order acceptance and payment authorization have separate availability.

What do the nines mean?

  • 43,2 min minAllowed downtime per month
  • 8,76 hPer year

Approach 43 Minutes per month: A single longer disruption consumes the budget. A frequently chosen goal for core functions.

Select an availability destination and read off the allowed downtime (month =) 30 Days, year = 365 days. Then switch to the payment provider and watch as availabilities deteriorate in series.

Tactics

This is how the architecture achieves the goal

This building block specifies and measures whether a function is usable; the tactics below are separate building blocks that achieve this goal.

  1. Detecting errors

    In the shop you notice that the payment service gets caught before customers fail at the checkout.

  2. Catching errors

    If the payment provider does not reply, the order acceptance remains usable instead of failing.

  3. Restoration

    After a failure, orders and functions return with tested procedures.

Benefits & limitations

Helps if:

  • A mission-critical function requires a coordinated goal for interruption and recovery.
  • External or internal dependencies can affect different parts of a service.

Boundaries

  • A percentage says nothing about how outages are distributed. A continuous 43-minute outage during a promotion has a different impact from scattered minutes at night. Specify the maximum duration of individual outages and critical time windows, then measure these as an SLO for each function.
  • Redundancy does not guarantee fast recovery and is ineffective when instances share a failure source, such as the same database or payment provider. Test restart and data restoration using Recovery Procedures, and identify remaining shared failure sources.

In practice

  1. Define the function and user success. State what successful availability means and for whom. This anchors the measurement in a real system capability.
  2. Agree the target, period and error budget. Agree a measurement window and permitted deviation with business stakeholders and operations. Connect the target to SLIs and SLOs so measurements support operational decisions.
  3. Test failure boundaries and recovery. Simulate relevant outages and check how the function and its data are restored. Recovery describes the procedures that support the target during an incident.
Read the detailed explanation

Availability refers to a specific function over a defined period. A technical process may be running while the capability that matters to users is failing. Define the success criterion, measurement point and time window. SLIs, SLOs & Error Budgets connects measurement to targets; Recovery covers restoration after an outage.

Architecture and operations limit the impact of failures through redundancy, isolation, restart procedures and alternative flows. Each measure introduces costs and dependencies of its own. Regular failure and restart tests add evidence about failure causes and recovery time, checking whether the target holds under realistic conditions.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    How much failure per month allows a target of 99,9 %?

    View the solution with justification

    Round 43 Minutes per month ()43,2 min at 30 days and about 8,76 hours per year.

  2. ApplyingTransferred to a new situation

    A customer will give 10:06 another order, while the provider does not respond. What can the shop do?

    View the solution with justification

    He can accept the order, because the order acceptance remains usable. Payment authorization is disrupted during this period, so the clarification is still open.

  3. EvaluateWeighing an alternative

    Should the shop report “Payment failed” immediately if there is no reply in order not to let the customer wait?

    View the solution with justification

    This quickly provides clarity. The disadvantage: A lack of response does not prove a business failure, and the payment could be authorized. The status clarification is technically more honest.

Explore further

These building blocks continue the thoughts of this page.

RequirementsQuality attributesYou define measurable expectations for how well a function performs under specific conditions.Opening OperationsRecoveryRecovery restores data and functionality after a failure using verified procedures.Opening OperationsTimeoutA timeout limits waiting time. Here you learn how the caller handles the resulting state.Opening DistributionPartial failuresHere you learn how to handle failed participants and uncertain outcomes in distributed workflows.Opening

References

Continue on the learning path

Next in Requirements & quality: Performance.

6 Building blocks

Continue withPerformance