The Principles of Consensus: Quorums and WAN Latency Bounds
Distributed consensus algorithms (like Raft and Paxos) enable a cluster of independent computers to agree on a shared state or sequence of events, even in the presence of network partitions or node failures. These protocols form the foundation of highly available databases like CockroachDB, Etcd (Kubernetes state store), and Spanner. Sizing the performance of these systems requires modeling WAN latency matrices.
Consensus protocols rely on a Quorum—a strict majority of active nodes—to approve any write operation before it is committed to the log. The quorum size required is: $$Q = \left\lfloor \frac{N}{2} \right\rfloor + 1$$ where \(N\) is the total number of consensus nodes. In a 5-node cluster, a quorum requires agreement from at least 3 nodes. The fault tolerance limit (the number of nodes that can fail without halting the cluster) is: $$F = \left\lfloor \frac{N - 1}{2} \right\rfloor$$. A 5-node cluster can tolerate up to 2 failed nodes.
To map performance metrics inside a microservice network, you can trace tail latency profiles using the API latency SLA calculator or audit cluster connectivity limits with the system reliability uptime calculator. Consensus latency is typically the primary write performance bottleneck in distributed databases.
Let's calculate the commit latency for a Raft cluster distributed across three global regions: US East (Virginia), US West (Oregon), and Europe West (Ireland). The leader node is located in US East. The Round-Trip Times (RTTs) from US East are: to US West = 65 ms, and to Europe West = 85 ms. In Raft, the leader must replicate the log entry to a quorum. Since the leader itself counts toward the quorum, it only needs a response from the closest node to reach 2 out of 3 votes. The closest node is US West (65 ms). Thus, the commit latency is 65 ms, showing how quorum math bypasses the slowest nodes.
The location of the consensus leader is the most critical variable. If the client is in Europe, but the leader is in US East, the client request experiences a network transit delay to the leader (85 ms), followed by the leader's quorum replication cycle (65 ms), and finally the response transfer back to Europe (85 ms), resulting in a total client-side commit latency of $85 + 65 + 85 = 235\text{ ms}$. Sizing leader placement close to your primary users is essential to minimize system latency.