Cloudflare explains why Meerkat uses the unusual QuePaxa consensus algorithm

What Cloudflare is building

Cloudflare has announced Meerkat, an experimental distributed consensus service built to manage its internal global control plane. According to the Cloudflare blog, Meerkat runs on QuePaxa — an unusual choice, since most production consensus systems rely on well-established algorithms such as Raft, Multi-Paxos, or Viewstamped Replication.

Meerkat itself is a replicated log: replicas agree on an ordered sequence of events, each one decided by the consensus algorithm, which guarantees that machines never decide conflicting values and therefore that the replicas' logs never diverge. On top of that log, Meerkat exposes a key-value store in which each entry is a get or a put, putting it in the same family as Consul, etcd, and Apache ZooKeeper. The difference, Cloudflare says, is scale: a Meerkat cluster can be spread across continents and connected by links with high and unpredictable latency, whereas consensus systems are typically deployed on smaller, local networks with strict latency requirements.

Why standard consensus struggles on the Internet

Cloudflare argues that common consensus algorithms degrade disproportionately when network conditions worsen, even when no machine actually crashes. The company saw this firsthand in 2020, when the partial failure of a core network switch caused a consensus-powered system to degrade: the Cloudflare dashboard ran 80 times slower than usual for six hours. No data was lost, but the system could not accept writes until the problem was resolved.

The blog points to two traits that cause this behaviour, which it names destructive interference and fault detection.

Destructive interference is easiest to see in Paxos, the algorithm most later designs inherit from. In Paxos, proposers send ballot numbers to a majority of acceptors in a Prepare phase, then submit a proposal in an Accept phase. When two or more proposers act at once, one can insert a higher ballot number between the other's two phases and block it, and the competitors can repeatedly stall each other. The more concurrent proposers, the more likely the system gets stuck proposing — even if every replica is healthy. Formally, Cloudflare notes, Paxos does not guarantee liveness without an assumption of partial synchrony, meaning messages will eventually arrive within some bounded time.

Most deployed algorithms — Raft, Multi-Paxos, and Viewstamped Replication among them — avoid this by electing a single leader that is the only replica allowed to propose. That imposes an order on requests and lets decisions complete in a single network round trip instead of two. While the leader is healthy and the network behaves, leader-based protocols are fast.

The leader is the weak point

The trade-off is that the leader must stay operational and reachable. If it fails, slows down, or gets cut off from the cluster, the whole system stalls until the remaining replicas detect the failure and elect a replacement. And, as Cloudflare observes, leader recovery is precisely where destructive interference sneaks back in.

In Raft, a replica that suspects the leader has failed announces itself as a candidate and asks the others for votes. If several replicas suspect failure at the same time, they compete for the majority and can block one another — the same interference pattern as competing Paxos proposers. Each failed election invites more candidates, so the disruption can continue even after the original fault disappears. Cloudflare describes this as a metastable failure: a failure pattern that perpetuates itself once the initial cause is gone. A two-second network outage, or a briefly faulty switch, can make a healthy leader appear dead, trigger an election that fails, and set off further elections that persist far longer than the outage itself.

How QuePaxa fits

Meerkat's answer is QuePaxa, which Cloudflare says promises better stability under volatility largely because it does not depend on a leader to make progress, and which the company says sidesteps both destructive interference and fault-detection problems. That matters for Meerkat's deployment environment in particular: at global scale, faults are more likely to originate in the network than in Cloudflare's own servers, so the algorithm has to tolerate latency spikes and broken connections rather than just replica crashes.

Why it matters

Consensus underpins coordination infrastructure across the industry — etcd sits behind Kubernetes clusters, and ZooKeeper coordinates countless distributed systems. Cloudflare's argument is that the leader-based algorithms dominating production were shaped for datacenter-scale networks, and they behave badly on the wide-area Internet where latency is high and links flap. The 2020 incident illustrates the cost: not data loss, but hours of write unavailability triggered by a single switch glitch. If QuePaxa holds up in Meerkat at global scale, it offers a template for any system that must reach consensus across continents — and a real-world test of whether newer, less battle-tested algorithms can displace Raft and Paxos in production. Cloudflare still calls Meerkat experimental, so the evidence will accumulate only as it runs.