Skip to content
Software Architecture Guide

Architectural Decisions for Availability

Explanation

Section titled “Explanation”

The first choice is which components must be highly available. Servers can be single points of failure, so they often deserve a close look. More redundancy (spare or duplicate parts) raises availability, but it also raises cost and complexity.

Architects then walk through guiding questions. Each answer is a design decision. Design decisions that shape how a system responds to a quality goal are called tactics (see Availability Tactic).

Allocation of responsibilities. Someone or something must own each task:

  • Detecting faults. The system cannot act on a fault until it has detected or anticipated it.
  • Handling exceptions. After the system detects an exception, it must handle it somehow.
  • Masking faults. The system can compare results from several redundant components, so users never see the fault.
  • Degraded operation. The system keeps its most critical functions running while some elements fail.

Coordination model. Parts of the system need a way to notice availability problems. A Heartbeat is one way: components exchange periodic messages, and a missing message signals trouble.

Exchangeability of parts. Reconfiguration recovers from a failed element by reassigning its responsibilities. That works only if parts can be remapped flexibly.

Resources. Critical resources must keep working in limited operation, because degraded operation depends on them.

See Fault Detection Tactic, Fault Recovery Tactic and Graceful Degradation for more detail.

Example

Section titled “Example”

An online shop decides that checkout must be highly available, while product reviews need not be. The team assigns one component to detect failures with periodic messages. If the payment service fails, a spare takes over its work. If reviews fail, the shop still lets people check out.

Trade-offs

Section titled “Trade-offs”

Redundancy buys availability, but it adds cost and complexity. Marking every component as highly available is therefore expensive. The decision about which components need it is itself a trade-off.

Checks

Section titled “Checks”
  • The document states which components must be highly available and why, for example servers that are single points of failure.
  • The document assigns responsibility for detecting faults and for handling detected exceptions.
  • The document describes how the system keeps its most critical functions working when elements fail.
  • The document explains how failed elements are replaced or their responsibilities reassigned.
  • The document names the cost and complexity of redundancy that was accepted.
Section titled “Related”

Sources

Section titled “Sources”