Distributed Consensus
Distributed-systems architecture at the protocol level: consensus (Raft, Paxos, BFT), replication…
by claude-dev-suite · MIT
The skill
Distributed-systems architecture at the protocol level: consensus (Raft, Paxos, BFT), replication and quorums, consistency models, clock synchronization, and the CAP/PACELC trade-offs. Architect-level — how to make state agree and survive failures. USE WHEN: designing replicated/consensus systems, "Raft", "Paxos", "BFT", "quorum", "leader election", "consistency model", "linearizability", "CAP", "PACELC", "split-brain", replication topology, distributed state machines. DO NOT USE FOR: app microservice wiring (use web/enterprise patterns); message queues (use messaging skills); blockchain specifics (use bitcoin skills).
Distributed Consensus & Replication
Consensus protocol selection
| Protocol | Fault model | Notes |
|---|---|---|
| Raft | Crash-fault (f of 2f+1) | Understandable, leader-based; default for etcd/Consul |
| (Multi-)Paxos | Crash-fault | Foundational, subtle; powers Spanner/Chubby lineage |
| BFT (PBFT, Tendermint) | Byzantine (f of 3f+1) | For untrusted/adversarial nodes; higher msg cost |
| Viewstamped Replication | Crash-fault | Raft-like, predates it |
Use crash-fault consensus inside a trust boundary; use BFT only when nodes can be malicious (cross-org, blockchain) — it costs more nodes and messages.
Replication & quorums
- Quorum: W + R > N for read-your-writes; tune (e.g. N=3, W=2, R=2).
- Leader-based (strong, simple, leader bottleneck) vs leaderless (Dynamo-style, available, needs read-repair/anti-entropy + conflict handling).
- Sync vs async replication = durability/latency vs RPO on failover.
Consistency models (state the one you need)
Linearizable → sequential → causal → eventual. Stronger = more coordination = higher latency / lower availability. Don't ask for linearizable if causal suffices.
CAP / PACELC
Under a Partition choose C or A; else (no partition) trade Latency vs Consistency. Real systems are points on a spectrum (Spanner: CP + TrueTime clocks; Dynamo: AP). Clocks: avoid relying on wall-clock ordering; use logical / hybrid logical clocks, or bounded-uncertainty clocks (TrueTime) for external consistency.
When to recommend what
- Config/coordination, small cluster → Raft (etcd).
- Global strong consistency → Paxos/Spanner-style + synchronized clocks.
- High availability, geo, conflict-tolerant → leaderless Dynamo-style + CRDTs.
- Adversarial/multi-party → BFT.
Use this skill
Connect your agent to the Skill Store MCP server and ask for it by ref: claude-dev-suite/distributed-consensus-62338009285.
Details
- Publisher
- claude-dev-suite
- Category
- Software Development › Misc
- License
- MIT
- Updated
- 2026-10-19
References
More from claude-dev-suite
- Axe Core axe-core - accessibility testing engine for automated WCAG compliance checks.
- Wcag WCAG 2.2 Web Content Accessibility Guidelines.
- Anthropic Python Anthropic Python SDK for Claude API integration.
- Decision Model Calibration Turning a model's class probabilities into numbers you can set a threshold on: building the label…