Skip to content

PATTERN Cited by 1 source

Leaderless consensus for WAN

Pattern

Choose a leaderless consensus protocol (e.g., QuePaxa) over leader-based alternatives (e.g., Raft) when the deployment environment is a wide-area network with unpredictable latencies and no tolerance for single-point-of-failure unavailability.

When to apply

  • Replicas span multiple geographic regions connected by the public Internet
  • Network latencies vary wildly and unpredictably
  • Any single replica failure must not cause write unavailability (no leader dependency)
  • The workload is write-infrequent, consistency-critical control-plane data
  • You have experienced production incidents from leader unavailability or election storms

Trade-offs

Gains: - System never becomes unavailable due to a single replica failure - No leader elections that degrade performance during transitions - Concurrent proposals cooperate rather than destructively interfering - No timeout tuning headaches

Costs: - Higher per-write latency for non-leader proposals (3+ round-trips vs 1) - More complex protocol implementation and formal verification - Less mature ecosystem and operational tooling compared to Raft

Cloudflare instance

Cloudflare chose QuePaxa for Meerkat after experiencing multiple production incidents from unavailable leaders in Raft-based systems. Their 330+ data center WAN has latencies that "can and do vary wildly," making timeout configuration intractable.

Seen in

Last updated · 573 distilled / 1,747 read