Preface¶

Cloudflare runs a large number of internal services across 330+ data centers worldwide, and these services need to read and write the same control plane state across regions—for example, the placement of AI model instances, database primary node election information, etc. This type of data must satisfy two hard constraints: strong consistency (all readers see the same consistent view of the system) and high availability (writes can still be performed when a single data center or network link fails).

In July 2026, the Cloudflare Research team published a blog post formally introducing the experimental consensus service Meerkat. Built on the QuePaxa consensus algorithm proposed by EPFL researchers in 2023, it allows any replica to initiate writes without relying on leader election and timeout mechanisms. Cloudflare stated that this would be the first industrial-scale deployment attempt of QuePaxa at a global scale. Authoritative media such as InfoQ followed up with reports shortly after, sparking widespread discussion in the distributed systems community.

This article organizes the design motivations and core architecture of Meerkat, as well as the essential differences between QuePaxa and Raft, to help readers understand the value and limitations of this “leaderless global consensus” experiment.

Control Plane Consensus: Why Cloudflare Needs Meerkat¶

Strong Consistency and Fault Tolerance¶

Cloudflare’s requirements for control plane data systems can be summarized into two points:
1. Linearizability: After a client writes, all subsequent read operations will see that write; concurrent reads and writes will not exhibit strange behaviors like “time travel”.
2. Majority-based fault tolerance: Tolerate f failures among 2f+1 replicas; as long as a majority of replicas are alive and reachable, clients in any data center can complete reads and writes.

The write frequency of control plane data is usually low, but the consistency requirements are extremely strict—a wrong leader election or state inconsistency could lead to cascading failures in global routing and resource scheduling. The Cloudflare blog admitted that the team has encountered multiple production incidents caused by Raft-style leader unavailability in the past.

The “Tyranny of Timeouts” of Raft in Wide Area Networks¶

Raft is currently one of the most mainstream consensus algorithms, with a clear implementation and mature ecosystem. However, its authoritative leader model exposes structural problems in cross-continental wide area networks like Cloudflare’s:
- Leader is the only write entry point: When the leader goes down or network conditions deteriorate, all writes will block until a new leader is elected.
- Timeout values are difficult to tune: Wide area network latency fluctuates drastically—setting a short timeout will trigger frequent false election attempts, while setting a long one will slow down fault recovery; simultaneous campaigns by multiple replicas will also interfere with each other, forming “election storms”.
- Leader becomes a performance bottleneck: When the leader is overloaded or the link slows down, the overall cluster write throughput will drop.

Cloudflare refers to this type of problem as “tyranny of timeouts”—partially synchronous algorithms rely on timeouts to make progress, but the internet environment cannot provide a stable timeout baseline.

QuePaxa: Escaping the Tyranny of Timeouts¶

Algorithm Background¶

QuePaxa was published at SOSP 2023 by researchers Tennage, Băsescu, et al., with the paper title Escaping the Tyranny of Timeouts in Consensus. Unlike partially synchronous algorithms such as Paxos and Raft, QuePaxa is designed for asynchronous networks and does not rely on timeouts to advance consensus, allowing it to continue making decisions even when message delays fluctuate sharply.

Its core design points include:
1. Any replica can drive consensus: Clients can submit requests to any replica, which can then initiate a proposal for the latest log slot without waiting for a leader.
2. Leader is optional rather than required: A leader role exists in QuePaxa, but its advantage only lies in reducing round-trip times (leader proposals take about 1 RTT, while non-leader proposals take about 3+ RTTs); leader failures will not block the system.
3. Constructive interference of concurrent proposals: When multiple replicas propose simultaneously, the replicas cooperate to select a unique value, rather than causing destructive conflicts like in Raft elections.
4. Clients can concurrently contact multiple replicas: The same proposal can be sent to multiple replicas at the same time to improve success rates.

The paper authors reported in their WAN-scale prototype experiments: Under harsh conditions such as DoS attacks, misconfigurations, and slow leaders, QuePaxa’s throughput is about ~10x that of Raft and Multi-Paxos, while the median latency remains at the sub-second level.

Meerkat Architecture Overview¶

Consensus Log¶

The core of Meerkat is a globally replicated consensus log. The log is composed of a series of slots: decided slots contain events, and the last slot is currently being decided. The key invariant is: any two replicas must agree on the value of the same decided slot.

The workflow is as follows:
1. Developers apply for a Meerkat replica cluster, specify the data centers where replicas can be deployed, and Meerkat will automatically place them.
2. The client sends application requests (such as KV get / put) to any replica.
3. The replica translates the request into a log event and distributes it to all replicas via QuePaxa.
4. Upper-layer applications (such as transactional KV stores, distributed lease systems) read the log events and rebuild a consistent state locally.

To ensure linearizability, read operations (get) will also write to the log—if a read replica has not yet seen the slot where the previous write resides, the majority will force it to synchronize old decisions first, then record the read event in a new slot, thereby linearizing the read after the write.

Upper-layer Applications¶

Meerkat itself does not parse the log content, which is consumed by upper-layer applications. Currently planned applications include:
- Transactional key-value storage: Supports compare-and-swap and general transactions.
- Distributed lease/lock system: Used for scenarios such as database leader election.

Meerkat is explicitly not a general-purpose database, and is only targeted at small control plane states with low write frequency and high consistency requirements.

Three Advantages of QuePaxa Over Raft¶

The Cloudflare blog summarizes three reasons for choosing QuePaxa for Meerkat, all directly related to wide area network operation experience:

In the InfoQ report, community developers pointed out that QuePaxa is an asynchronous consensus algorithm, which is the essential difference from partially synchronous solutions such as Paxos/Raft; some practitioners also questioned whether the extra round-trip delay is worth it—Cloudflare responded that control plane scenarios have sparse writes, so availability takes priority over extreme latency.

Performance Evaluation and Optimization Methods¶

The inherent cost of consensus algorithms is multiple rounds of network round trips. QuePaxa usually takes 1–3 RTTs to decide a proposal (leader proposal: 1 RTT + broadcast notification; non-leader proposal: 3 RTTs + broadcast; concurrent proposals may take more). Decision latency is proportional to the RTT between a majority of replicas—when replicas are distributed across continents, the latency cannot be avoided.

Meerkat provides the following performance optimization methods:
1. Controllable replica placement: Developers specify the data centers where replicas are located, and services that do not require global strong consistency can deploy replicas closer to users.
2. Write batching: Multiple writes in a short period are merged into a single proposal to improve throughput.
3. Optional weakly consistent reads: Allow reading slightly stale but consistent data from local replicas, skipping the consensus round.
4. Single-round multi-operation: Operations such as compare-and-swap can be completed in one consensus round.

Cloudflare emphasized that the fundamental latency limit of Meerkat objectively exists in wide area network scenarios, so it is most suitable for control plane information with infrequent writes and non-compromisable consistency.

Current Progress and Future Plans¶

As of the July 2026 blog post release, the status of Meerkat is as follows:
- Not yet deployed in production: Positioned as an experimental internal service, remaining internal-only in the near term.
- Completed multiple rounds of PoC (Proof of Concept), running on up to 50 global replicas; during the PoC, leaders continued to fail, but the cluster error rate did not rise.
- Implemented in Rust, the team plans to conduct formal verification on part of the implementation.
- A series of articles will be released in the coming year, covering QuePaxa details, cluster bootstrapping and management, optimal replica placement, deterministic simulation testing (DST), etc.; at the same time, academic paper submissions are being prepared.

Cloudflare Research engineers James Larisch, Bob Halley, and João Pedro Leite are the main authors of the Meerkat project.

Community Observations and Open Questions¶

Discussions about Meerkat on communities such as Hacker News focus on several directions:
- The first production-grade implementation of asynchronous consensus? If Meerkat is finally launched, QuePaxa will become one of the few asynchronous consensus solutions that has moved from papers to industrial practice.
- Performance competitiveness in normal scenarios: The ~10x throughput advantage under harsh conditions is obvious, but whether the extra RTT is acceptable in daily low-latency WAN deployments still requires more benchmark data.
- Open source and specifications: Some developers hope that Cloudflare will release design specifications and verification details to allow the community to reproduce and audit the system.

Cloudflare has not yet announced a production launch timeline or production-level latency data. For external developers, Meerkat is currently more of an important reference for distributed consensus engineering practices rather than a directly usable open source component.

Summary¶

Cloudflare Meerkat attempts to use QuePaxa to solve a real and widespread problem: how to use consensus algorithms to manage global control plane state on unpredictable wide area networks, while avoiding availability traps caused by leaders and timeouts. It does not provide a new general-purpose database, but offers another algorithm option for “strongly consistent, low-write, highly available” control plane scenarios.

For engineers paying attention to distributed systems, the value of Meerkat lies in: it brings the asynchronous consensus idea from the 2023 QuePaxa paper to real-scale validation on 330+ data centers and 50-replica PoC; whether it is finally fully put into production or not, this engineering path itself is worth tracking continuously.

References:
- Cloudflare Official Blog: Introducing Meerkat - an experiment in global consensus
- InfoQ: Cloudflare Introduces Meerkat for Strongly Consistent Global Coordination
- QuePaxa Paper: Tennage & Băsescu et al., SOSP 2023, Escaping the Tyranny of Timeouts in Consensus