Skip to content
Software Architecture Guide

Availability Tactic Categories

Explanation

Section titled “Explanation”

A tactic is a design move that helps a system reach a quality goal. For availability (how much of the time a system works), tactics fall into three major categories: detect faults, recover from faults, and prevent faults.

Detect faults. These tactics notice that something has gone wrong. Three examples:

  • Heartbeat: a monitor and the monitored process exchange messages at regular intervals.
  • Ping/echo: one node sends a request and another node answers. The exchange is asynchronous.
  • Exception detection: the system recognizes a condition that changes the normal flow of execution.

Recover from faults. These tactics restore service after a fault. Graceful degradation is one of them. The system keeps its most critical functions running while components fail, and it drops less critical functions. The arc42 quality model describes the same idea as keeping functionality when parts of a system break down.

Prevent faults. These tactics stop a fault from turning into a failure. Two examples:

  • Removal from service: the team temporarily takes a component out of service to head off likely failures.
  • Redundancy: extra components stand ready. In active redundancy, also called a hot spare, all components belong to the active group. A cold spare recovers poorly, so it has a high MTTR (mean time to recovery).

Measuring the result. Availability is the percentage of time a workload is available over a period, such as a month or year. It is often expressed in nines, such as 99.9%. You can estimate it from MTBF (mean time between failures) and MTTR. With an MTBF of 150 days and an MTTR of 1 hour, the estimate is 99.97%.

Independent redundant components raise the theoretical figure. Two independent 99.9% components together give 99.9999%.

Example

Section titled “Example”

An online shop wants its checkout to stay available. The team adds a heartbeat so a monitor notices when the payment service stops responding (detect). It runs a second, always-active payment instance (prevent). If both fail, the shop keeps browsing and the cart working and turns off recommendations (recover, by graceful degradation).

Trade-offs

Section titled “Trade-offs”

More redundancy gives higher availability, but it also raises cost and complexity. Higher availability targets also call for recovery automation and thorough testing. So identify the true availability need before designing. A cold spare is cheaper to keep than a hot spare, but it has a high MTTR. Choose and combine tactics from each category to fit the target.

The three categories of availability tactics with examples.

Diagram source 
flowchart LR
 A[Availability tactics] --> B[Prevent faults]
 A --> C[Detect faults]
 A --> D[Recover from faults]
 B --> B1[Redundancy]
 B --> B2[Removal from service]
 C --> C1[Heartbeat]
 C --> C2[Ping/echo]
 C --> C3[Exception detection]
 D --> D1[Graceful degradation]

Checks

Section titled “Checks”
  • The document names which tactics cover each of the three categories: detect, recover and prevent.
  • Each redundancy choice states its cost and complexity impact.
  • The availability target is stated as a percentage over a period, and the need for it is justified.
  • The recovery time (MTTR) of spare-based redundancy is stated.
Section titled “Related”

Sources

Section titled “Sources”