| name | distributed-consensus |
| description | Distributed consensus algorithms and logical time for cloud and multi-node systems. Covers Lamport clocks, vector clocks, FLP impossibility, Paxos (basic, multi, fast), Raft, Viewstamped Replication, Byzantine fault tolerance basics, quorum reads/writes (N/R/W), leader election, and TLA+ specification style. Use when designing replicated state machines, picking a consensus protocol, reasoning about split-brain and quorum loss, or writing formal specs for distributed coordination. |
| type | skill |
| category | cloud-systems |
| status | stable |
| origin | tibsfox |
| modified | false |
| first_seen | "2026-04-12T00:00:00.000Z" |
| first_path | examples/skills/cloud-systems/distributed-consensus/SKILL.md |
| superseded_by | null |
Distributed Consensus
Consensus is the problem of getting a group of processes that fail independently to agree on a single value, or on a sequence of values, in the presence of network delays, message loss, and process crashes. Consensus is the foundation on which replicated state machines, leader election, distributed locks, configuration management, and strongly consistent databases are built. This skill catalogs the core results, algorithms, and design heuristics a cloud-systems practitioner needs to reason about coordination primitives without reinventing them.
Agent affinity: lamport (consensus theory, logical clocks, TLA+), decandia (quorum mechanics in Dynamo-style stores), dean (Paxos/Spanner experience in production systems)
Concept IDs: cloud-multi-service-coordination, cloud-procedure-execution, cloud-requirements-tracing
Why Consensus is Hard
Distributed systems fail in ways that single-node systems do not. Messages arrive late, arrive out of order, arrive twice, or never arrive. Processes crash, restart, and come back with stale state. Networks partition and heal. Clocks drift. Two observers watching the same sequence of events can see them in different orders and both be telling the truth about what they saw. Building reliable systems on this substrate requires algorithms that are correct under the worst combinations of these failures, not just the common cases.
The core insight, due to Lamport, is that "time" in a distributed system is not a physical thing — it is a partial order over events derived from message causality. "Happened-before" (a -> b if a and b are on the same process in program order, or if a is a send and b is the matching receive) gives a causal structure that distributed algorithms can actually reason about. Wall-clock time is an optimization for the common case, not a correctness foundation.
The FLP Impossibility Result
Fischer, Lynch, and Paterson (1985) proved that in an asynchronous system with even one faulty process, no deterministic consensus algorithm can guarantee termination. The proof constructs an adversarial scheduler that can always delay messages to keep the system in a bivalent state — a state from which either decision is still reachable.
This result does not say consensus is impossible. It says that any consensus algorithm must give up something: either synchrony assumptions (Paxos, Raft assume partial synchrony and eventually a stable leader), or determinism (randomized consensus terminates with probability 1), or fault tolerance (can tolerate zero failures if synchrony is strong). Every real consensus algorithm sits somewhere on this trade-off curve.
Lamport Clocks
A Lamport logical clock is a function L from events to integers satisfying: if then . The simplest implementation is a per-process counter :
