Series and parallel formulas need a shared mission and independence

For a series success rule, every required component must succeed during the defined mission. The exact probability is their joint success probability; a product of marginal reliabilities requires mutual independence. Serial dependency does not mean physical cabling must form a straight line. A user request needing an API, authentication service, and database can have series logic even though their network topology is complex. Probabilities must describe the same condition and horizon: mixing annual mission reliability, instantaneous availability, and per-request success creates a number with no coherent interpretation.

For independent exponential no-repair lifetimes, component survival is exp(−λt), and a required series path's rates add. A rate has inverse-time units; survival is dimensionless. This mission-survival model says no component failed before time t and is different from the fraction of time a repairable service is working. A component that fails and is repaired during a day may be available at the day's end while having failed the no-failure mission. State which question the model answers instead of labeling all probabilities uptime.

For an ideal parallel success rule, the system succeeds if at least one required alternative succeeds. Its failure event is the intersection of all alternative failures. Independent alternatives give one minus the product of their failure probabilities. The model assumes that a surviving alternative has the capacity, data, routing, and activation needed to serve. A standby that cannot take load in time is not a successful alternative for a short user deadline. Failover logic can itself be a required component or a conditional activation probability.

Shared dependencies belong outside the independent-alternative product unless a richer conditional model justifies another placement. Two compute replicas using the same failing credential, regional network, or configuration are not automatically independent service paths. A load balancer required by both paths can cap the combined success probability. Redundancy may also introduce complexity and synchronization failure modes. Compare the complete modeled service success rule, not just the component-level improvement achieved by adding a second worker. The next lesson makes common causes explicit rather than hiding them in an optimistic product.

A required shared component can dominate an otherwise excellent redundant subsystem. Improving a nonbinding leaf may yield less user benefit than removing a common dependency or making failover credible. Compute alternatives with explicit assumptions, then vary uncertain inputs and inspect whether the decision changes. The arithmetic is most useful as a model comparison and a prompt for evidence collection. Many decimal places do not establish the rare-event accuracy of estimated component figures or prove a future service objective.

The binomial lab shows independent identical alternatives. Reset, explicitly set BOTH p=0.9 and n=2, predict all-success probability 0.81 and at-least-one probability 0.99, then Play or Step. Reset and re-set BOTH p=0.9 and n=3; predict 0.729 and 0.999. Edits retain t; playback only highlights exact probability bars. The same distribution supports different series or parallel questions depending on which counts qualify. It includes no repairs, shared failures, switching delay, capacity saturation, or actual dependency graph.