consensus-and-quorumslisted

# Consensus And Quorums ## Purpose Consensus is a set of processes agreeing on **one value** with safety despite modeled crashes, loss and delay; progress additionally needs a quorum and timing assumptions such as eventual synchrony. Consensus can order a replicated log used for grants and configuration, but is not itself a lock or lease. Leases, locks, role election and shard ownership have distinct contracts; not every election uses a lease, and ownership can change dynamically. Route external stale-owner safety to `distributed-locks-and-leases` and role lifecycle to `leader-election`. The failure this prevents is a coordination store used as a traffic-scaled database. etcd, ZooKeeper and Consul are replicated metadata/coordination stores with different read contracts; writes pass through a leader/quorum log and durable storage, often batched/pipelined. Business rows, a work queue or a per-request job table in one makes every business write a consensus decision — and puts the store's availability in series with the service's, which is the arithmetic in `failure-models`. ## Workflow This skill is protocol-level and has no Java language minimum. For a Java integration inspect the project toolchain, resolved client version, deployed server version, read options and durability/failover policy. Product references here cover etcd 3.6 and ZooKeeper 3.8.4; verify Consul modes against the deployed version. Do not upgrade Java or the store to match a reference. Missing membershi