fault tolerance
A jet airliner can lose an engine in mid-flight and still fly safely to a landing. That is fault tolerance: the ability of a system to keep delivering correct service even when some of its parts fail. The goal is not to make components that never break — that is impossible — but to arrange them so that the failure of a part does not become the failure of the whole. A fault-tolerant system absorbs a fault and carries on, ideally without the user noticing anything happened.
How is it built? Almost always with some form of redundancy: spare resources that can take over or check the work. Simple examples: error-correcting codes add redundant bits so a flipped bit is corrected on the fly (see error-correcting-code); RAID stores data across several disks so one disk dying loses nothing (see raid); a server can have two power supplies so one failing leaves the machine running. A classic scheme is triple modular redundancy, where three units compute the same thing and a voter takes the majority answer — if one unit is wrong, the other two outvote it. Each technique trades extra hardware, power, or time for the ability to survive a fault.
It is worth being honest about the limits. Fault tolerance is about masking faults you anticipated, up to some assumed number — typically 'survive any single failure'. It does not make a system invincible: correlated failures (a power outage that kills all the redundant supplies at once), design bugs replicated across every copy, or simply more faults than you provisioned for can still bring the whole down. And redundancy is not free; doubling hardware for reliability is a real cost, so engineers tolerate exactly as many faults as the application's stakes justify — far more for avionics or a bank than for a desktop.
Triple modular redundancy: three identical adders all compute the same sum, and a small voter circuit outputs whichever value at least two of them agree on. If a soft error flips a bit in one adder, the other two still agree, the voter picks the correct answer, and the fault is masked — the rest of the system never sees it.
Three compute, a voter takes the majority: one faulty unit is outvoted, so a single fault never reaches the output.
Redundancy only helps if failures are independent. A flood, a shared power feed, or the same design bug in every copy can take down all the 'redundant' parts at once — the most expensive fault-tolerance failures come from correlated faults you assumed away.