Interview Prep Zoneby CuriouserLabs

Question 1 of 5 · staff level

Why is agreeing on a single value hard, and what does the FLP result actually forbid?

🎤 Say this first

Consensus means every correct node decides the same value, that value was proposed by someone, and every correct node eventually decides. FLP (1985) proves that in a purely asynchronous model — no bound on message delay, no synchronized clocks — no deterministic algorithm can guarantee all three if even one node may crash. The reason is beautifully simple: you cannot distinguish a crashed node from a slow one, so any algorithm that waits forever risks blocking, and any algorithm that gives up risks disagreeing. Real systems escape FLP not by beating it but by weakening a requirement: they add partial synchrony (timeouts as a failure detector) and settle for always safe, eventually live — Raft and Paxos never return two different answers, but they can stall while leaders churn.

The full picture

  • The three properties, named precisely: agreement (no two correct nodes decide differently), validity (the decided value was proposed — rules out the trivial 'always decide 0' algorithm), termination (every correct node eventually decides). FLP says you can't have all three deterministically under asynchrony with one crash fault.
  • Safety vs liveness is the escape hatch: production consensus keeps safety absolute (never two leaders committing conflicting entries) and makes liveness conditional on the network behaving 'well enough'. That's why an etcd cluster under a flapping network doesn't corrupt — it just stops accepting writes. Losing availability is the designed behavior, not a bug.
  • The Two Generals problem is the sibling result for reliable messaging: with a lossy channel you can never achieve common knowledge, so acknowledgements never terminate. Practical consequence you actually live with: there is no such thing as exactly-once delivery — only at-least-once delivery plus idempotent processing.
  • Byzantine vs crash faults: Raft/Paxos assume nodes crash or go silent but never lie. Tolerating lying nodes (Byzantine) costs 3f+1 replicas instead of 2f+1 and much heavier protocols (PBFT, HotStuff) — worth it for blockchains, overkill inside your own datacenter. Naming which fault model you assume is a mark of precision.
  • Timeouts are a failure detector, and they're always wrong sometimes: too short → false positives → unnecessary leader elections and lost throughput; too long → slow failover. This single tuning knob is where most real consensus-cluster incidents actually live.

🔄 Likely follow-up questions

  • Why can't you distinguish a crashed node from a slow one, even in principle?
  • Which property does Raft sacrifice during a network partition, and what does that look like to a client?
  • When would you actually need Byzantine fault tolerance?