# Quantifying Recovery and Availability Trade-offs

**In short:** You can estimate availability from how often a part fails and how fast it is repaired. Redundancy raises that estimate, but cost, takeover time, and slow responses pull the other way.

## Explanation

**Estimating availability.** Two numbers drive a first estimate. MTBF is the mean time between failures. MTTR is the mean time to repair. Availability is MTBF divided by (MTBF + MTTR). With an MTBF of 150 days and an MTTR of 1 hour, the result is about 99.97%.

These numbers explain what drives availability and how to improve it. They are not an empirical measure of availability, so treat the result as an estimate.

**What redundancy adds.** Suppose components are independent and redundant. Then theoretical availability is 100% minus the product of their failure rates. Two 99.9% components give 99.9999%. This is a best case. It assumes independence and ignores the cost of failover (switching to the spare) and of keeping the spare in sync.

**How current the spare is.** The Redundant Spare tactic has three variants: active redundancy (hot spare), passive redundancy (warm spare), and spare (cold spare). A cold spare starts with none of the failed node's state. A hot standby avoids that. In hot-standby PLC (industrial controller) setups, the primary sends its process image after every scan, and the standby confirms it is in sync. Takeover then takes about one or two scan cycles, typically 10 to 50 ms.

**Performance and availability interact.** A response slower than the client's timeout looks like a failure to the client. A design that makes responses slow can therefore lower availability, even when every component is up.

## Example

A team runs a controller with a standby. They first compute the availability of one controller from its MTBF and MTTR. They then compute the redundant ideal from the failure rates of both units. Next they ask two more questions. How current is the standby's state at takeover? Does keeping it current slow normal responses past the client timeout? The ideal figure is a best case. The answers to those questions show how far the real design may fall short.

## Trade-offs

Higher availability usually costs more. It also demands more testing and recovery automation. Confirm the real availability need before choosing a design.

The redundancy formula looks generous because it leaves out failover and sync costs. Keeping a standby fully current can improve takeover, but it adds work that can affect response time. Slow responses can then count as failures.



## Checks

- The document states the availability target and how it was estimated, for example from MTBF and MTTR.
- Any redundancy-based availability figure states its assumptions, such as independence, and says whether failover and sync costs are included.
- The standby type (hot, warm, or cold) is named, and the state the standby holds at takeover is described.
- The document justifies the availability level against its cost, testing, and recovery automation needs.
- Response-time limits (client timeouts) are considered when judging availability.

## Related

- [Availability](https://arc.fuet.ch/concepts/quality-attributes/availability.md)
- [Redundant Spare](https://arc.fuet.ch/concepts/tactics/redundant-spare.md)
- [Active Redundancy](https://arc.fuet.ch/concepts/tactics/active-redundancy.md)
- [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md)
- [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md)
- [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- [Performance Efficiency](https://arc.fuet.ch/concepts/quality-attributes/performance-efficiency.md)
- [Battlefield Control System ATAM Case Study](https://arc.fuet.ch/concepts/evaluation/battlefield-control-system-atam-case-study.md)

## Sources

- [Availability - Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) — docs.aws.amazon.com, accessed 2026-11-09
- [Measuring availability - Availability and Beyond: Understanding and Improving the Resilience of Distributed Systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html) — docs.aws.amazon.com, accessed 2026-11-09
- [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
- [How Hot Standby CPU Redundancy Works: Synchronized Failover for Critical Process Control - KY Automation](https://www.kyautomation.com/news/4949.html) — kyautomation.com, accessed 2026-11-09