4.2Reliability design

When a system architect designs redundancy, the simplistic idea that "duplicating a component brings peace of mind" is not enough, because how the components are connected (in series or in parallel) determines the overall availability via an entirely different formula. Furthermore, how a system should behave the instant a failure occurs—continue operating fully, degrade its functionality, or stop safely—has a different optimal answer depending on business requirements. This section builds the judgment to weigh a target level of reliability/availability against cost when choosing a configuration, grounded in the RASIS metrics, series/parallel availability calculation, and the three behavioral patterns under failure.

4.2.1The five RASIS metrics

• RASIS is an acronym for five metrics that evaluate system reliability from multiple angles. Reliability is how infrequently failures occur (measured by mean time between failures, MTBF). Availability is the degree to which the system is usable when needed (measured by availability/uptime ratio). Serviceability is how easily the system recovers from a failure (measured by mean time to repair, MTTR). Integrity is the degree to which data remains consistent and correct. Security is resistance to unauthorized access and information leakage.
• In practice, an architect does not try to maximize all five RASIS metrics equally, but instead judges which metric to prioritize given the business requirements. For example, a payment system prioritizes integrity (data correctness) and availability above all, while a minor internal tool prioritizes serviceability (being cheap to fix); making tradeoff priorities explicit is at the core of the design judgment.

4.2.2Series/parallel availability calculation

• A series configuration requires every component to be functioning for the whole to work (e.g., a single path from web server to database server). Overall availability is calculated as the product of each component's availability (a1 x a2 x ... x an). Note that adding more components in the chain actually lowers overall availability—for example, chaining two components each with 99% availability in series yields overall availability of 0.99 x 0.99 = 0.9801 (98.01%).
• A parallel configuration (redundancy) provisions multiple components with the same role, such that the whole functions as long as at least one is working (e.g., two web servers behind a load balancer). Writing a single unit's availability as a and the count as n, overall availability is calculated as 1 - (1 - a)^n (one minus "the probability that all units fail simultaneously"). For example, putting two units each with 90% availability in parallel raises overall availability to 1 - (1 - 0.9)^2 = 1 - 0.01 = 0.99 (99%)—parallelization pushes availability upward.

4.2.3Fault tolerant, fail-soft, and fail-safe

• Fault tolerant is a design philosophy in which, even if a component fails, the system keeps all functions running with no impact on users. Duplicated components run concurrently at all times, and if one fails, another instantly takes over processing. This is the costliest design approach and is used in domains such as payment infrastructure or air traffic control, where a functional stoppage is not acceptable.
• Fail-soft is a design philosophy that keeps operating even if it means degrading functionality upon failure (graceful degradation). For example, if some servers fail, the system stops non-critical functions and keeps offering only the critical ones. It costs less than fault tolerance and suits requirements where complete stoppage is undesirable but full redundancy is not required. Fail-safe is a design philosophy that reliably transitions to a safe state upon failure (continuing to function is not the goal). For example, if a control system detects an anomaly, it errs on the side of preventing dangerous behavior even at the cost of stopping function (such as traffic signals defaulting to all-red).

Suppose an online brokerage's system architect is designing an order-execution system with a target availability of 99.99% (roughly 52 minutes or less of downtime per year). Measuring the current single-server configuration first shows an availability of 99% (a = 0.99). Since the target cannot be met with a single-unit configuration, the architect considers raising availability through parallelization (redundancy). Putting two servers, each with 99% availability, in parallel yields overall availability of 1 - (1 - 0.99)^2 = 1 - 0.0001 = 0.9999 (99.99%), exactly meeting the target. But there is a critical point not to overlook here: if the load balancer or shared storage upstream of these servers remains a single point of failure (a series-connected element), the overall availability is dragged down by that bottleneck even after the servers are parallelized. For example, if the load balancer's availability stays at 99.9%, the overall figure drops to 0.999 x 0.9999 ~= 0.9989 (99.89%), missing the target. The design judgment, therefore, is that every series-connected component—not just the server tier but the load balancer, shared storage, and so on—must be parallelized (made redundant). At the same time, as a cost tradeoff, rather than making every component fault tolerant (zero downtime), classifying the core order-execution function as fault tolerant while non-critical functions such as reference-data display are fail-soft (degraded operation) achieves the target availability while avoiding over-investment. A typical misjudgment here is assuming "duplicating just the servers is enough to hit the target availability"—because the lowest-availability element along the entire series-connected path (the bottleneck) caps the overall availability, a redundancy design that accounts for the whole path is essential.

4.2.4Section summary

• The five RASIS metrics are prioritized according to business requirements, not maximized equally
• Series availability is a product (falls with more elements); parallel (redundant) availability is 1 - (1 - a)^n (rises with more units)—the weakest element on the whole path caps the result
• Choose among fault tolerant (keeps functioning, costly), fail-soft (continues in degraded form), and fail-safe (stops to a safe state) based on business requirements and cost