06.01 · Short-concept
Why State Ruins Everything
State the system model and failure model you are working under, because every guarantee below depends on which one you assumed.
State and failure models define what your reliability claims actually mean. Timing bounds, message loss, clock behaviour, storage durability, crash assumptions and Byzantine behaviour all change which guarantees are possible. Without those assumptions, words like consistent, available and fault tolerant are not engineering properties, just slogans.
What this lesson answers
- what is a distributed system failure model
- why do consistency guarantees need system assumptions
- how do partitions affect availability and consistency
Notes
System and Failure Models — System and failure models exist to make guarantees falsifiable: without stating timing, communication, storage, and crash assumptions, claims like “consistent,” “available,” or “fault tolerant” become meaningless and break under a different network delay, clock, or failure pattern.
Key Concepts: - A synchronous model assumes known bounds such as message delay and clock drift ; an asynchronous model assumes no finite upper bound on message delay or process speed. - A fail-stop model means a node halts and stays halted, e.g.
Common questions
- Why do I need to state a system model before discussing consistency?
- Consistency is only meaningful under stated assumptions about timing, communication, clocks, storage and failures. A design that is safe with bounded clock skew or reliable disk writes may fail when those assumptions change. The model tells reviewers exactly what world the guarantee applies to, and where it stops applying.
- What is the difference between crash faults and Byzantine faults?
- With crash faults, a process stops and no longer participates. With Byzantine faults, a process can do arbitrary things, including sending conflicting information to different peers. Byzantine tolerance is a much stronger requirement, so protocols need different assumptions, more defensive validation and usually more replication.
- Can a timeout prove that another node has failed?
- A timeout can only show that a response did not arrive within the chosen interval. In an asynchronous model, a slow process, long pause or delayed network can look the same as a crash. Treating timeout as proof of failure smuggles in a timing assumption that the system may not actually satisfy.