Cloudflare Details Meerkat: A WAN-Optimized Consensus Service Powered by QuePaxa
Cloudflare has unveiled Meerkat, an experimental, internal consensus service designed to replace Raft-based systems for global control-plane state management across more than 330 data centers. Utilizing the QuePaxa consensus algorithm, Meerkat enables concurrent writes across all replicas and eliminates leader-election timeouts to maintain availability during WAN partition events.
WAN Latency and the Limits of Raft
Managing control-plane state across Cloudflare’s network of over 330 data centers requires strong consistency guarantees, specifically linearizability. Traditional deployments often rely on Raft-based consensus systems to achieve this. However, Raft's reliance on a single leader replica introduces significant availability bottlenecks in wide-area networks (WANs) characterized by unpredictable latencies, packet loss, and fiber cuts.
Under Raft, only the designated leader replica can process writes. If the leader fails or experiences network degradation, the entire system becomes unavailable for writes until a follower replica detects a timeout and initiates a new leader election. Configuring these timeouts is difficult in globally distributed networks. Setting them too low causes spurious elections due to transient network spikes, while setting them too high prolongs system downtime. These limitations have directly contributed to multiple operational incidents within Cloudflare’s infrastructure.
QuePaxa and the Meerkat Architecture
To address these WAN-specific vulnerabilities, Cloudflare’s Research team developed Meerkat. Meerkat is built on QuePaxa, a consensus algorithm published in 2023 by Tennage & Băsescu et al. Unlike Raft, QuePaxa allows all replicas to execute write operations concurrently without relying on a centralized leader.
Because the algorithm does not depend on leader-election timeouts to resume operations, progress is never halted when individual replicas or network links degrade. Replicas participate in a peer-to-peer network where each node is connected to every other node. To interact with the system, clients dispatch application-specific requests, such as key-value operations or lease requests, to any available replica in the cluster.
Fault Tolerance and Consistency Guarantees
Meerkat is engineered to tolerate up to $f$ faults within a cluster of $2f + 1$ replicas. The system guarantees write and read availability to any client that can establish communication with a replica connected to a majority of live machines. This model prevents single-link failures from interrupting service availability, a failure mode common in Raft when the link to the active leader is severed.
While Meerkat does not handle Byzantine faults, it ensures safety against machine crashes, restarts, and network partitions. The system enforces linearizability, meaning all operations appear to execute atomically at a discrete point in time. Additionally, the transactional key-value store built on Meerkat supports serializability.
Log Replication and Application Integration
At its core, Meerkat replicates an ordered log of arbitrary events. When a replica receives an application request, it translates the request into a log event. This event is distributed to all other replicas via the QuePaxa algorithm to ensure every node maintains an identical sequence of events.
Applications are layered directly on top of this log. Each replica hosts application instances, such as a key-value store, which sequentially read the log events to construct local, in-memory state. To guarantee up-to-date reads and prevent stale data retrieval, read requests are also processed as distributed log events rather than being served locally without consensus coordination.