Consensus Cluster Calculator — Raft/Paxos Quorum, Availability & Commit Latency
Size a Raft or Paxos cluster: majority quorum, fault tolerance, binomial quorum availability, M/M/1 queueing, and expected plus tail commit latency over LAN, WAN, or global links.
Distributed Consensus Network Latency Solver
| Follower | dist | RTT | P(ok) |
|---|---|---|---|
| N1 | 350.00 km | 7.25 ms | 99.8001% |
| N4 | 650.00 km | 10.36 ms | 99.8001% |
| N2 | 900.00 km | 12.80 ms | 99.8001% |
| N3 | 1.400 K km | 17.84 ms | 99.8001% |
A clear path from inputs to results.
Size and time a replicated consensus cluster (Raft or Paxos) before you deploy it. It works out the quorum you need, how many node failures you can survive, how available that quorum is given per-node reliability, and how long a commit round takes once network propagation, serialization, queueing, jitter, and retries are added up — with a Monte Carlo pass for the tail percentiles.
How to use
- Choose the protocol (Raft or multi-phase Paxos) and a deployment scenario (LAN, metro, WAN, or global) that sets representative inter-node distances, link rate, jitter, and loss.
- Set the cluster size N. The engine derives the majority quorum, the acknowledgements the leader must collect, and the number of simultaneous node failures the cluster tolerates.
- Enter the link rate, request payload size, per-node processing delay, mean jitter, packet-loss probability, and retry timeout to build the per-round latency budget.
- Set the per-node reliability as a number of nines and the client distance; the engine computes node and quorum availability from the binomial of independent nodes.
- Enable queueing and set the offered load (ops/s) to model each node’s egress link as an M/M/1 server and add the mean waiting time to the round.
- Read the quorum size, fault tolerance, quorum availability, M/M/1 utilization and wait, and the expected and tail (p99-style) commit latencies from the Monte Carlo trials.
The formula
Reference: Raft majority-commit and timing rules (Ongaro & Ousterhout, “In Search of an Understandable Consensus Algorithm,” 2014); Paxos prepare/accept phases (Lamport, “Paxos Made Simple,” 2001); binomial quorum availability; M/M/1 queue mean wait W_q = ρ/(μ−λ) (Kleinrock, Queueing Systems).
Worked example
Five-node Raft cluster over a WAN
- Raft; N = 5; WAN scenario (nearest follower 350 km); link rate 1000 Mbps; payload 4096 bytes; processing 0.2 ms/node; mean jitter 1.5 ms; loss 0.1%; retry timeout 250 ms; per-node reliability 3 nines (0.999); offered load 250 ops/s with queueing on.
- 1
Quorum sizing: majority q = ⌊N/2⌋ + 1 = ⌊5/2⌋ + 1 = 3, so the leader needs 2 follower acknowledgements and the cluster tolerates ⌊(N−1)/2⌋ = 2 node failures. Availability: with per-node p = 1 − 10⁻³ = 0.999, quorum availability is the binomial tail A = Σ(j=3..5) C(5,j) pʲ(1−p)⁵⁻ʲ = 0.99999999, about 8.00 nines. Queueing: each ack round sends F·payload + client-response bits = 4×4096×8 + 128×8 = 132,096 bits, so the service rate is μ = 10⁹ / 132,096 = 7570 ops/s; at λ = 250 ops/s the utilization is ρ = 250/7570 = 0.033 and the M/M/1 mean wait is W_q = ρ/(μ−λ) = 0.00451 ms. Round latency to the nearest (350 km) follower: two one-way propagations 2×(350×0.005) = 3.50 ms, request/response serialization 0.0328 + 0.0010 ms, processing 0.2 ms, queue 0.0045 ms, and 2× mean jitter 3.00 ms sum to 6.738 ms; dividing by the success probability p_ok = (1−0.001)² = 0.998 and adding retry inflation ((1−p_ok)/p_ok)×250 = 0.501 ms gives an expected round of 7.25 ms.
Majority quorum = 3 (tolerates 2 failures); quorum availability ≈ 0.99999999 (≈8 nines); M/M/1 μ = 7570 ops/s, ρ = 0.033, W_q = 0.0045 ms; expected single-round latency to the nearest follower ≈ 7.25 ms, dominated by WAN propagation and jitter. Commit waits for the quorum-completing (second) follower, and the Monte Carlo pass extends this to the tail percentiles.
Interpreting the result
Three quantities drive the design. The quorum q = ⌊N/2⌋+1 fixes both safety (how many acks commit a log entry) and fault tolerance (⌊(N−1)/2⌋ failures survived) — note that going from N=5 to N=6 does not improve fault tolerance, only cost. Quorum availability climbs steeply with per-node reliability: three-nines nodes already give roughly eight-nines quorum availability at N=5, because a majority must fail simultaneously. Latency, by contrast, is dominated on a WAN by round-trip propagation and jitter, not by serialization or queueing at modest load; the queue only matters as offered load λ approaches the service rate μ, where W_q blows up.
Assumptions & limitations
- Node failures are independent and identically distributed; correlated failures (shared power, network partitions, same availability zone) make real quorum availability lower than the binomial estimate.
- Each node’s egress link is modeled as a single M/M/1 server with Poisson arrivals and exponential service; real traffic is burstier, so W_q is a lower-bound approximation and diverges as ρ → 1.
- Packet loss is i.i.d. Bernoulli with geometric retries; the model is stretched at high loss (flagged above ~10%) where correlated loss and congestion collapse dominate.
- Propagation uses ~5 µs/km (fiber at ~2×10⁸ m/s) over the scenario distances; it ignores routing detours, middlebox processing, and last-mile variance beyond the entered jitter.
- Quorum sizing, fault tolerance, availability, M/M/1 statistics, and the deterministic per-round latency are exact closed forms; the commit-latency percentiles come from a seeded Monte Carlo and will vary with the trial count and seed.
Frequently asked questions
How are the quorum and fault tolerance computed?
The majority quorum is q = ⌊N/2⌋ + 1, and the cluster tolerates f = ⌊(N−1)/2⌋ simultaneous failures. For N = 5 that is a quorum of 3 and tolerance of 2. The leader needs q−1 = 2 follower acknowledgements since it counts its own vote. This is the standard Raft/Paxos majority rule.
Why add more nodes if fault tolerance does not always improve?
Fault tolerance is ⌊(N−1)/2⌋, so N = 5 and N = 6 both tolerate 2 failures — the even node only adds cost and a larger quorum to coordinate, raising latency. Odd cluster sizes (3, 5, 7) are preferred because each added pair of nodes buys one more tolerated failure without a wasted member.
When does the M/M/1 queue term start to matter?
When offered load λ approaches the per-node service rate μ. Here μ = 7570 ops/s and λ = 250 ops/s give ρ = 0.033 and a mean wait of only 0.0045 ms. Because W_q = ρ/(μ−λ), the wait grows slowly until ρ ≈ 0.7 and then explodes toward ρ = 1, which is where larger payloads or higher load would dominate the round.
Why does five-nines-ish node reliability give eight-nines quorum availability?
Because a majority must fail at once for the quorum to be lost. With N = 5 and per-node availability 0.999, the quorum is unavailable only if 3 or more nodes are down simultaneously, whose binomial probability is about 1×10⁻⁸. So the quorum availability is roughly 0.99999999 — about eight nines — far better than any single node, which is the whole point of replication.
What limits commit latency on a WAN?
Round-trip propagation and jitter. In the worked example the two one-way hops to the nearest follower contribute 3.5 ms and the jitter term 3.0 ms, while serialization (0.034 ms) and queueing (0.0045 ms) are negligible at 250 ops/s. Commit itself waits for the quorum-completing (second-fastest) follower, so geographically spreading nodes trades availability for latency.
How does packet loss inflate the round?
A round succeeds with probability p_ok = (1−loss)² (request and response each survive). The expected round is base/p_ok plus a retry-inflation term ((1−p_ok)/p_ok)×retry-timeout. At 0.1% loss that adds about 0.5 ms; at high loss the retry-timeout term dominates the tail, which is why the tool warns once loss exceeds ~10%.
Methodology last reviewed 2026-10-06. Results are informational and not financial or engineering advice — see our disclaimer.