In the context of consensus protocols like Raft, what's the difference between a 'safety' property and a 'liveness' property, and give an example of each being satisfied even when the other is temporarily violated?

## Safety versus liveness Every distributed protocol's correctness is usually specified as two separate kinds of properties: safety and liveness. - A **safety** property says 'nothing bad ever happens' - it's a statement about every reachable state of the system, and it can be violated by a single bad event at a single point in time. - A **liveness** property says 'something good eventually happens' - it's a statement about the long-run behavior of an execution, and it can only be violated by an infinite failure to make progress, never by any single moment. The classic intuition: safety is what you check by looking at a snapshot of the system; liveness is what you can only be sure was violated by watching forever and seeing it never happen. ## Raft's safety properties In Raft, the core safety properties include: - **Election Safety** - at most one leader can be elected in a given term. - **Leader Append-Only** - a leader never overwrites or deletes entries in its own log, only appends. - **Log Matching** - if two logs contain an entry with the same index and term, the logs are identical in all preceding entries. - **Leader Completeness** - if an entry is committed in a given term, it will be present in the logs of leaders for all higher-numbered terms. - **State Machine Safety** - if a server has applied a log entry at a given index, no other server will ever apply a different entry at that index. These are proven to hold unconditionally, regardless of how many messages are delayed or lost and regardless of how many nodes crash and restart, as long as a majority of nodes are never simultaneously destroyed. ## Why liveness is conditional Raft's liveness property, by contrast, is much weaker and explicitly conditional: if a majority of servers can communicate for a sufficiently long period, a leader will be elected and stay elected, and progress will be made. That hedge - 'sufficiently long period' - is not an accident; it's a consequence of FLP impossibility (Fischer, Lynch, Paterson, 1985), which proves that in a fully asynchronous network with no bound on message delay, no deterministic consensus protocol can guarantee both safety and termination if even a single process can fail. Since real networks can't guarantee bounded delay, every practical consensus protocol keeps safety unconditional and makes liveness depend on 'partial synchrony' - the network behaving reasonably for long enough stretches, even if occasionally chaotic. ## What a partition looks like This is why, during a network partition, the correct expected behavior is for the minority side of a Raft cluster to stop making progress entirely rather than guess. Consider a 5-node cluster split into a group of 3 and a group of 2. - The group of 2 can't reach a majority, so its nodes keep timing out, incrementing their term, and calling elections that never succeed - liveness is violated for that side, indefinitely, until the partition heals. - But at no point does that group of 2 elect a leader or accept a write with only 2 acks, so Election Safety and State Machine Safety are never broken. - The group of 3 keeps a leader and keeps committing writes - safety and liveness both hold there. The system as a whole deliberately sacrifices availability on the minority side to preserve consistency everywhere. ## The trade-off The trade-off this represents is fundamental, not accidental: a system could instead choose to always stay live, always respond to every request even during a partition, but then it must give up strict safety, allowing two sides of a partition to independently accept conflicting writes (this is what AP-leaning systems like default multi-master stores do, accepting the possibility of write conflicts that must be reconciled later). Raft, like Paxos-based systems, is firmly on the CP side of that spectrum: it will happily become completely unavailable rather than risk two leaders in the same term. ## The failure mode in production The failure mode this produces in production is a cluster that appears 'stuck' - clients see write timeouts, not errors, because the minority-side nodes are still up and responding to health checks, just unable to commit anything. Operators unfamiliar with this distinction sometimes misdiagnose a stalled minority partition as a crash and try to force an unsafe fix (like manually promoting a minority node to leader), which is exactly the kind of action that breaks the safety guarantees the protocol worked hard to preserve. A concrete real instance: etcd clusters that lose quorum (e.g., 2 of 3 nodes down) go fully read-write-unavailable rather than let the surviving single node serve writes - this is intentional and documented behavior, and the correct recovery is to restore quorum, not to force single-node operation, which is why etcd explicitly requires an operator to use a special disaster-recovery procedure, not routine promotion, to break this guarantee when truly necessary.