Learn

Learning preferences

Make learning more comfortable. Changes apply immediately.

Enlarges page content, including diagrams and their labels. You can also use your browser’s zoom.

Choose the colours that are easiest for you to distinguish. Applies to lesson diagrams and lab plots. Labels, shapes, hatching and line patterns also distinguish meanings. Source photographs and raw image brightness stay unchanged; mask-only views are available for image overlays.

ExampleComparisonSample link

Saved in this browser on this device. Preferences are separate from progress backups.

Learn through experiments

Extra copies cannot fix every failure

When does redundancy improve an entire service?

Entering midway? Revisit How a short surge becomes repeated swings for the preceding worked example, or start here and use the explanation below.

1 · Try

Start with a concrete question

Original synthetic scenario. A service needs every serial stage to work. Each stage can have one component or two independent parallel components; a shared outage disables all.

Try the initial inputs, then write a prediction before changing one setting. All calculations run locally on your CPU.

Go directly to the experiment · Review basic mathematics

2 · Predict

What do you expect?

If each of three stages works 90% of the time, is the whole service also available 90%?

3 · Experiment

Change one thing. Inspect what happens.

  1. Compare one and three serial stages at 90% component availability.
  2. Add parallel copies and compute the two-failure probability for one stage.
  3. Add a 20% shared outage and identify the availability ceiling.
  4. Choose an improvement and explain which failure class it addresses and which it leaves unchanged.
Experiment inputs
Inputs
Your settingsMechanism
Calculation belowEvidence
Compare outcomes
Stage availability outside shared outage90 %
Whole-system availability72.9 %
Unavailable fraction27.1 %

Compare the current results

Every bar starts at zero and uses the same numeric scale in this chart. The upper bound automatically adjusts to the largest current value (at least 1), so compare the numbers when changing inputs. Units and quantities come from each label; different kinds of quantity are not interchangeable. Displayed values are rounded to at most six significant digits.
072.9
  • System available (%)72.9
    System available (%): 72.9Horizontal bar from zero to 72.9, on the shared zero to 72.9 numeric axis.
  • System unavailable (%)27.1
    System unavailable (%): 27.1Horizontal bar from zero to 27.1, on the shared zero to 72.9 numeric axis.

Follow the calculation

  1. Each component independently works with probability 0.9 outside shared outages.
  2. Each stage uses one component: availability 0.9.
  3. All 3 serial stages must work: 0.9^3 = 0.729.
  4. A shared outage disables the entire system with probability 0; final availability = (1 − 0) × 0.729 = 0.729.

Parallel redundancy can reduce independent failures, but a shared failure cause sets a ceiling that extra copies cannot eliminate.

Captures keep your inputs, prediction and observation. Results are recalculated from those inputs. Resetting inputs keeps your captures and challenge history.

4 · Understand

Explain the mechanism

What the experiment explains

Original synthetic scenario. A service needs every serial stage to work. Each stage can have one component or two independent parallel components; a shared outage disables all.

A series system needs every stage. Under independence, multiply stage availabilities: 0.9³ = 0.729, or 72.9%.

Two parallel components fail together with probability 0.1²=0.01, so stage availability becomes 99%. Three such stages give 0.99³≈97.03% before shared outages.

A common cause breaks the independent-copy benefit. A 20% shared outage limits total availability to at most 80%, even with perfect components.

Read the relationship

Parallel-stage availability = 1 − (1−p)². System availability = (1−q) × stage availability^k. p is component availability, q shared-outage probability, k serial stage count.

Inspect the evidence

The numerical trace is recalculated from your current settings. Compare a controlled pair of trials before changing several inputs together. Inspect intermediate quantities as well as final metrics; state which assumptions make the comparison meaningful.

Boundaries of the model

  • Independence outside the shared-outage state, instantaneous failover and perfect fault detection.
  • Static probabilities, not repair-time forecasts or empirical reliability estimates.

Return to the systems thinking and operations course and project to connect this mechanism to the broader investigation.

5 · Apply

Try a fresh case

Two independent components each work with probability 0.8. They are parallel backups, and an independent shared outage occurs with probability 0.1. What is system availability as a percentage?

This is a public practice check. Retries support learning; matching a number does not certify independent proficiency.

Take the investigation further

Choose any extension. These are project prompts for you to carry out; they are not automatically assessed.

School investigation

Enumerate success/failure cases for two components.

College investigation

Add imperfect failover and conditional failure dependence, then compare with this ideal baseline.

Workplace investigation

Create a reliability improvement brief separating independent failures, common causes, detection and recovery evidence.

6 · Continue

Keep the evidence, choose your next step

Completion records your own decision that you have worked through this investigation. Practice checks and independent project evidence are separate.