Skip to content

System reliability and redundancy

Combine component probabilities using series, parallel and k-out-of-n success rules, distinguish reliability from availability, and see why shared outages and imperfect failover limit redundancy.

System reliability is the probability that a system performs its required function without failure over a specified period and under stated conditions. Redundancy supplies additional components or paths so that some failures can be tolerated. For a trading service, the practical question is which combinations of working feeds, gateways and workers actually deliver the required service. Adding a backup helps only if the system can use it when needed.

Decide what “working” means

For a non-repairable system with failure time TT, reliability is the survival function:
R(t)=P(T>t).R(t)=\mathbb{P}(T>t).
This is the probability of surviving beyond a horizon, as defined in the NIST reliability handbook.
Availability instead asks whether the service is operational at a specified instant, potentially after earlier failures and repairs. PTC's reliability documentation makes this distinction explicitly. A service can recover before an order arrives and therefore be available to that order, even though it did not run without interruption throughout the day.
The same success logic can combine either kind of probability. Its inputs must describe the same event convention and horizon. A 90% snapshot availability is neither a failure rate nor a mean time to failure, and does not say that 90% of complete trading sessions are interruption-free.

The same three components give three answers

Consider a fictional service during a fixed one-hour trading window. At a selected request instant in that window, each of three components is operational with probability p=0.9p=0.9. Assume their up/down states are mutually independent. These are stipulated snapshot probabilities, not measurements of real infrastructure.
Let NN count the operational components. Its binomial distribution assigns probabilities 0.0010.001, 0.0270.027, 0.2430.243 and 0.7290.729 to N=0,1,2,3N=0,1,2,3, respectively. Now change only the success requirement:
ConfigurationService is available when…CalculationAvailability
SeriesAll three components workp3p^372.9%
Two out of threeAt least two work3p2(1−p)+p33p^2(1-p)+p^397.2%
ParallelAt least one works1−(1−p)31-(1-p)^399.9%
State-selection grid for three independent components with snapshot up probability 0.9 each. The count probabilities for zero, one, two and three up are 0.1%, 2.7%, 24.3% and 72.9%. Series selects only three up and totals 72.9%; two of three totals 97.2%; parallel selects one, two or three up and totals 99.9%.
State-selection grid for three independent components with snapshot up probability 0.9 each. The count probabilities for zero, one, two and three up are 0.1%, 2.7%, 24.3% and 72.9%. Series selects only three up and totals 72.9%; two of three totals 97.2%; parallel selects one, two or three up and totals 99.9%.
Original synthetic snapshot model. Each total sums the probability masses of the states that satisfy its success rule.

“Series” describes functional dependence, not necessarily physical wiring: a feed, a risk check and an order gateway may all be necessary to submit a valid order. “Parallel” could describe three interchangeable workers, each capable of serving the request alone. If one worker lacks sufficient capacity, “one working” is the wrong success event.

For independent component up probabilities p1,…,pnp_1,\ldots,p_n, NIST's series model multiplies the success probabilities. Its parallel model multiplies failure probabilities and takes the complement:
Pseries=∏i=1npi,Pparallel=1−∏i=1n(1−pi).P_{\text{series}}=\prod_{i=1}^n p_i, \qquad P_{\text{parallel}}=1-\prod_{i=1}^n(1-p_i).
With identical independent inputs, the kk-out-of-nn rule generalises both:
Pk-of-n=P(N≥k)=∑j=kn(nj)pj(1−p)n−j.P_{k\text{-of-}n} =\mathbb{P}(N\ge k) =\sum_{j=k}^{n}\binom{n}{j}p^j(1-p)^{n-j}.

The factor (nj)\binom{n}{j} counts which jj components work. This binomial sum requires a common pp as well as independence; unequal probabilities need a different count calculation. For non-repairable, independently surviving components, substituting Ri(t)R_i(t) for pip_i gives the corresponding reliability at tt.

Independence is where the impressive decimals can disappear

Three components can each have marginal availability 0.9 and still fail together. In the extreme model where all three share exactly the same up/down state, every configuration above has availability 0.9. Component probabilities alone do not determine system availability; the joint distribution matters.
A less extreme model adds a shared outage with probability c=0.01c=0.01. If it occurs, every path is unavailable. Conditional on its absence, the nn local components are independent with up probability 0.9. By the law of total probability, the parallel service's unavailability is
qn=c+(1−c)(0.1)n.q_n=c+(1-c)(0.1)^n.
For three components, q3=0.01099q_3=0.01099, so availability is 98.901%. Here each component's unconditional availability is 0.99×0.9=0.8910.99\times0.9=0.891: the added outage changes the marginal probabilities too. This is an explicit two-layer model, not a correction that preserves the earlier 0.9 marginals.
Log-scale plot of synthetic parallel-system unavailability against one to six components. Without shared outages it falls from 10% to 0.0001%. With a 1% shared outage and conditional local up probability 0.9, it falls from 10.9% to 1.000099%, approaching a 1% floor. With three components the shared-outage model gives 1.099% unavailability.
Log-scale plot of synthetic parallel-system unavailability against one to six components. Without shared outages it falls from 10% to 0.0001%. With a 1% shared outage and conditional local up probability 0.9, it falls from 10.9% to 1.000099%, approaching a 1% floor. With three components the shared-outage model gives 1.099% unavailability.
Original conditional model. More parallel components reduce local simultaneous failure, while the stipulated shared-outage probability remains.
A shared power supply is a dependency that can be modelled explicitly; a common software defect can also defeat several nominally redundant copies. NASA's Fault Tree Handbook, §5.2, explains why ignoring common causes can severely understate system failure. The toy outage above is an explicitly modelled shared event, not NASA's beta-factor model for implicit common-cause failures.

A spare must be usable

The parallel formula assumes the remaining working component is enough to deliver service. It does not establish that a dormant backup starts, receives current state or takes over before a deadline. Failure detection, isolation and recovery can themselves fail; NASA's handbook, §8.2, calls the probability of successful recovery given a fault coverage. Repair, standby activation and switching delays require additional modelling.
For the underlying event algebra, the Series and parallel systems section of Independence derives both products and combines redundant links with a required gateway. The page has a public preview; the full lesson requires membership.

Sources

Last updated
  • reliability
  • redundancy
  • availability
  • independence
  • operational risk
Keep connecting the ideas
← Back to the glossaryBack to top ↑