# Architectural Decisions for Availability

**In short:** Designing for availability means asking structured questions: which parts must stay up, how faults are detected, and how the system keeps working when something fails. The answers become design decisions.

## 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

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

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

- 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.

## Related

- [Availability](https://arc.fuet.ch/concepts/quality-attributes/availability.md)
- [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics.md)
- [Heartbeat](https://arc.fuet.ch/concepts/tactics/heartbeat.md)
- [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md)
- [Fault Detection Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-detection.md)
- [Fault Recovery Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-recovery.md)
- [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)
- [Responsibility Allocation](https://arc.fuet.ch/concepts/functional-requirements/responsibility-allocation.md)

## Sources

- [Tactics and Patterns for Software Robustness | CMU Software Engineering Institute](https://www.sei.cmu.edu/blog/tactics-and-patterns-for-software-robustness/) — sei.cmu.edu, accessed 2026-11-09
- [3.4 Design Concepts to Support Availability | Making Design Decisions | InformIT](https://www.informit.com/articles/article.aspx?p=3197432&seqNum=4) — informit.com, accessed 2026-11-08
- [3.2 Design Concepts: The Building Blocks for Creating Structures | Making Design Decisions | InformIT](https://www.informit.com/articles/article.aspx?p=3197432&seqNum=2) — informit.com, accessed 2026-11-09
- [3.5 Design Concepts to Support Modifiability | Making Design Decisions | InformIT](https://www.informit.com/articles/article.aspx?p=3197432&seqNum=5) — informit.com, accessed 2026-11-09