Timing Models and Failure Detection

You cannot tell slow from dead

A timing model describes what you may assume about delays. In a synchronous system, message delays and processing speeds have known upper bounds, so a missing reply after the bound proves a crash. In an asynchronous system there are no bounds at all: a message may take arbitrarily long. Real networks are best described as partially synchronous: they behave synchronously most of the time, but may have periods (GC pauses, congested switches, VM migrations) where delays are unbounded. Consequently, the practical failure detector is a timeout, and a timeout can only suspect failure. If you choose a short timeout you detect crashes quickly but get false suspicions during load spikes; a long timeout avoids false alarms but leaves the system leaderless for longer. Consensus protocols are designed so that safety never depends on timing; only liveness (making progress) does.

Waiting for a reply on a call

You call a friend and hear silence. Maybe the call dropped, maybe they muted themselves, maybe they are thinking. After some seconds you decide to hang up and call again, but that decision is a guess, not proof. Timeouts in distributed systems are exactly this guess.

Safety vs liveness, the interview phrasing

Safety: nothing bad ever happens (two nodes never decide different values). Liveness: something good eventually happens (a value is eventually decided). Raft and Paxos guarantee safety under any timing and guarantee liveness only once the network is stable for long enough.

त्वरित जाँच: Why is a timeout only a suspicion of failure, not proof?

• Because timeouts are always configured too short
• Because clocks on different machines are never synchronised
• Because in a partially synchronous network a live node can be arbitrarily slow for a while
• Because TCP retransmits every lost packet