Skip to content

Availability Tactic

A fault is a defect or failing part inside a system (see the article Fault). Users notice a failure only when a fault spreads. Availability tactics are design decisions that stop this. The SEI report by Scott and Kazman treats tactics as building blocks for both designing and analyzing an architecture (see Architectural Tactic).

Self-healing combines fault detection with automatic recovery. The system recovers affected components itself and, if needed, fails over to redundant infrastructure.

Common recovery tactics include:

  • Retry. Many faults are transient, meaning they pass on their own. An operation that failed for such a fault usually succeeds if you wait and try again. Retry is the most common answer to these faults.
  • Checkpointing. The system saves its state along the way. After a failure, a long-running operation resumes from the saved state, for example on another instance. This is the basis of rollback and recovery.
  • Graceful degradation. When components fail, a separate workflow keeps the essential functions running in a reduced state.
  • Active redundancy. All copies run, so failover is immediate. It suits mission-critical workloads.
  • Passive redundancy. A primary instance handles all traffic. Idle standbys take over when it fails.
  • Cold spare. A redundant spare sized for full load but stopped. It must be started before failover.
  • Voting. In triple modular redundancy, three systems run the same process. A majority voter produces one output. This masks one faulty unit.

Relaxing consistency is also an availability-related design decision. Strong consistency needs coordination, which lowers throughput and couples systems tightly.

An online shop calls an external payment service. A call fails now and then, so the shop retries after a short wait. A long order export saves checkpoints, so a restart on another instance continues where it stopped. If the recommendation service goes down, the shop hides recommendations but still takes orders.

Tactics have costs. Active-active redundancy gives immediate failover, but it costs more and adds complexity. Active-passive is cheaper, but it accepts a brief recovery time. A cold spare is cheaper still to keep, but it must be started before it can take over. Strong consistency protects data agreement, but it reduces throughput.

Availability tactics act before, during and after a fault so it does not become a visible failure.

Diagram source
flowchart LR
F[Fault] --> D[Detect]
D --> R[Recover]
R --> S[Service stays available]
P[Prevent] -.-> F
  • The document names which recovery tactics protect each critical component, such as retry, redundancy or checkpointing.
  • Where redundancy is used, the document states whether it is active-active, active-passive or a cold spare, and why.
  • The document describes which essential functions stay available in a degraded mode when components fail.
  • The document records the cost and complexity trade-off of the chosen redundancy.