dependability
Raw speed is not the whole story of a good computer system. A bank's machine that processes a million transactions a second but occasionally loses one is useless; a storage system is judged not just on how fast it answers but on whether you can trust the answer and count on the system being there when you need it. Dependability is the umbrella word for that trust: the quality of a system you can rely on to deliver correct service and to keep delivering it. It bundles together ideas like reliability, availability, and fault tolerance.
The first thing to get straight is the chain of fault, error, failure. A fault is a flaw or defect — a cosmic ray, a worn-out flash block, a loose cable, a bug. A fault may cause an error — an incorrect internal state, like a flipped bit in memory. And an error, if it reaches the system's behaviour, causes a failure — the system delivers wrong service, like returning bad data or crashing. The crucial insight is that a fault need not become a failure: if you catch and fix the error first, the system keeps working correctly. That gap is where all of dependability engineering lives. Two standard measures quantify it: reliability, often summarized as mean time between failures (how long, on average, before it fails), and availability, the fraction of time the system is up and serving.
How do you turn faults into non-events? The master tool is redundancy — extra resources whose only job is to cover for failure. ECC adds redundant bits so a flipped bit is corrected, not delivered. RAID adds redundant disks so a dead disk does not lose data. Replicated servers let one take over when another dies. The honest framing: you cannot prevent every fault, so dependable design assumes faults will happen and arranges that they degrade gracefully rather than catastrophically. Redundancy is not free — it costs hardware, power, and complexity — which is why dependability is always a deliberate trade-off, not a default you get for nothing.
A cosmic ray flips a bit in server RAM (a fault, causing an error). Without ECC, that wrong bit could be read and a bad number returned — a failure. With ECC, the code detects and corrects the flip before the data is used: the fault and error happened, but no failure occurred. The system stayed dependable because redundancy absorbed the fault.
Fault → error → (caught by redundancy) → no failure. Breaking that chain is the whole game.
Distinguish fault, error, and failure — they are not synonyms. A fault that never propagates to wrong behaviour is not a failure. Good dependable design assumes faults are inevitable and stops them short of failure, rather than pretending they will not occur.