Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Only if the failure points are arranged in series - A AND B AND C must happen to have a successful outcome.

If the failure points are arranged in parallel - X OR Y OR Z must happen to have a successful outcome, with multiple redundant paths to success, your total failure rate is the chance that ALL of X, Y, and Z fail. This is a much lower number than when they are in series.

To use concrete math - say that Starship has 33 raptor engines with a failure rate of 0.01%, 3 grid fins with a failure rate of 0.05%, and a fuel tank with a failure rate of 0.001%. If it's engineered so that all 33 raptor engines, all 3 grid fins, and the fuel tank all need to work for a successful launch, the success rate of the whole system = 0.9999^33 * 0.9995^3 * 0.99999 = 0.9952 = ~0.5% chance of failure. If it's engineered so that it can get to orbit on 28 out of the 33 raptor engines, 2 out of the 3 grid fins, and there is a double-hull to the fuel tank with a failure rate of 0.005%, then the chance of failure for each subsystem is 0.0001^5 = 10^-20, 0.0005^2 = 2.5 * 10^-7, and 0.00001 * 0.00005 = 5 * 10^-10, and when you multiply out those subsystem failure rates you get 1 - (1 - 10^-20) * (1 - 2.510^-7) * (1 - 510^-10) = 0.9999997495 = ~0.000025% chance of failure.

Moreover, lets look what happens if you take the multiply-redundant design above and then increase the chance of failure of each component 100x. Raptor engines are now 99% reliable, grid fins are now 95% reliable, and fuel tanks are now 99.9% reliable. The overall failure rate for each subsystem becomes 0.01^5 = 10^-10, 0.05^2 = 2.5 * 10^-3 and 0.001 * 0.005 = 0.000005. When you multiply out those subsystem failure rates you get 1 - (1 - 10^-10) * (1 - 2.510^-3) * (1 - 510^-6) = 0.00250498759 = ~0.2% chance of failure. The multiply-redundant system, even with component failure rates 100x higher, still has better reliability than the perfectly-engineered system where every component must perform exactly to spec.

This principle is used all the time in practical engineering. It's why Google builds server farms out of thousands of commodity PCs, hooked up in primary/replica clusters with replication and transparent failover. It's why ships have watertight compartments and double-hulls. It's why passenger jets have multiple engines, multiple hydraulic control systems, and multiple flight computers. Any engineer worth their salt is going to avoid SPOFs and assume that components will fail, then build redundancies into the design so that a partial failure does not endanger overall mission success.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: