On July 8, 2026, Cloudflare Research announced Meerkat, an experimental consensus service that runs the agreement protocol across its 330+ edge data centers rather than within a single region. Meerkat runs QuePaxa, a 2023 algorithm from EPFL, in what Cloudflare calls the first industrial deployment of the protocol. The bet is that running consensus at the edge beats pinning it to one data center, and that only pays for workloads that tolerate the write-latency tax.
What is Meerkat, and how does it run consensus at the edge?
Meerkat is a consensus service whose replicas live across Cloudflare’s global points of presence, so a client can submit reads and writes to any replica in any data center and still get linearizable results. A developer requests a cluster of replicas and may constrain which data centers host them; Meerkat places the replicas and wires each to every other. Each replica participates in the protocol and accepts both reads and writes, translating application requests (a key-value get or put) into log events that the consensus algorithm distributes to all replicas. Every functioning replica ends up with the same ordered log, and applications layer atop the log to build state, with the KV application replaying events into an in-memory store.
The protocol is QuePaxa, published in 2023 by researchers at EPFL. Cloudflare chose it because it is leaderless in the way that matters for availability. There is a notion of a leader, but it is not required. Clients may contact any replica and may contact several concurrently for the same proposal without destructive interference. The blog describes replicas that ‘work together’ to decide one of the concurrently proposed values instead of fighting an election.
The fault model is the standard quorum one: the system stays available for reads and writes from any data center as long as a majority of replicas can communicate, tolerating f failures in a cluster of 2f + 1 machines, provided the client can reach any machine connected to that majority. A single crashed machine or a degraded link does not cost availability, which is the property a Raft cluster cannot guarantee without a working leader.
That is precisely why Cloudflare moved away from Raft-style systems. Raft funnels every write through an authoritative leader and elects a replacement by timeout. On a wide-area network where latency varies, timeout tuning becomes a reliability problem: too short and replicas depose a healthy leader; too long and a failed leader blocks writes until the timer fires. Cloudflare cites the motivating pain directly: it has ‘experienced multiple incidents caused by unavailable leaders in consensus-driven systems.’
What does a global quorum cost on every write?
Every write, and every linearizable read, must wait on round trips between a majority of replicas, and when those replicas are spread across continents the per-operation floor is intercontinental round-trip time rather than intra-datacenter microseconds. The constraint is structural: proposal latency is bounded below by the round-trip time between the replicas forming the majority.
Move that majority from one rack to points of presence on three continents and the floor on every commit becomes the RTT between the most distant quorum members. A quorum that waits on a transatlantic or transpacific hop pays tens of milliseconds per round trip, multiplied by the number of trips. Cloudflare concedes the point: ‘if your replicas are far from one another, latency will increase, there’s no getting around that.’
Cloudflare sketches four ways to claw latency back, all standard distributed-systems moves rather than Meerkat-specific machinery: co-locate replicas for services that do not need true global spread; batch writes that arrive within a short window; accept stale-but-consistent local reads where the application tolerates it; and bundle multiple operations into a single consensus round, which the KV store exposes as compare-and-swap and general transactions. None of these removes the quorum floor. They reduce how often you pay it.
How does Meerkat compare to Spanner, CockroachDB, and etcd?
Existing geo-distributed systems handle the cross-region problem one of three ways, and Meerkat differs from all of them by refusing to keep the quorum local. Spanner attacks the problem with clocks: Google’s TrueTime API exposes a bounded clock-uncertainty interval backed by atomic clocks and GPS, and Spanner waits out that uncertainty to assign commit timestamps that are externally consistent across regions. The writes still cross oceans, but the protocol can reason about time precisely enough to serialize globally without a per-write leader election. Meerkat does not rely on specialized timing hardware; its consistency comes from the replicated log and the consensus protocol, not from the clock.
CockroachDB and etcd both run Raft and both have a region-pinning story: keep the quorum, and in CockroachDB’s case the leaseholder, within a single region for latency, accepting that a region failure forces a failover to a slower remote quorum. The write path is fast in the common case because the majority is local. Meerkat inverts the trade. There is no region pin and no single authoritative leader to lose, so a replica or link failing does not trigger a leader election or block writes, but when replicas are globally distributed the quorum spans continents and every write pays the cross-region cost.
The cleanest framing is that CockroachDB and etcd optimize for fast writes by accepting leader-based failover risk, Spanner optimizes for correctness across regions by spending on clocks, and Meerkat optimizes for availability under network hostility by spending on write latency. These are different bets about which failure mode hurts more, not points on a single axis of better.
When does edge consensus actually pay off?
Meerkat pays off when reads vastly outnumber writes, when the workload is global, and when availability under flaky network conditions matters more than single-digit-millisecond writes. That profile matches exactly the workload Cloudflare names: control-plane state written infrequently but read often from everywhere, such as which machine currently leads a replicated database or where an AI model instance is placed. These are values a service might read on every request but write once on a failover or placement change. For that shape, a global consensus log that stays available when a leader dies is a reasonable exchange for slow writes.
The wrong fit is high-volume transactional data, and Cloudflare scopes the system accordingly: Meerkat is ‘being designed initially to manage small pieces of control plane state,’ not to serve as a general-purpose database. Pushing a per-request transactional workload through a protocol whose every commit waits on cross-continent round trips would be self-inflicted. The system’s own optimizations, batching and bundled multi-operation rounds, are admissions that the per-operation cost is high enough to need amortization.
The honest break-even question is one the announcement does not answer with numbers: at what read-to-write ratio and what geographic spread does the availability benefit exceed the write-latency tax? Cloudflare frames Meerkat’s central selling point as availability under the hostile network conditions where leader-based systems stall, and the architecture supports that claim. What the announcement does not do is characterize the latency of a write that has to round-trip a global majority.
What’s missing from the announcement?
Meerkat ships with strong architectural claims and no production latency benchmarks, no public availability timeline, and a scope deliberately capped at control-plane state. The blog is careful about what it does and does not claim. It publishes no write or read latency distributions, gives no throughput or scalability ceiling, and commits to no date for external availability, describing Meerkat as ‘kept internal-only for the immediate future.’ What it does promise is more detail: the blog describes this introduction as groundwork for ‘Meerkat-related blog posts to come.’
The conservatism is appropriate and probably correct. QuePaxa is subtle enough that Cloudflare has spent a year building Meerkat before trusting it with even control-plane state. The interesting claim, that running leaderless, timeout-free consensus across 330+ edge locations buys availability that region-pinned Raft cannot, is plausible and well-motivated by the incidents Cloudflare cites. The unproven claim is that the resulting write-latency tax is tolerable beyond a narrow control-plane niche, and on that the announcement is silent by design.
For practitioners, Meerkat is worth tracking but not yet worth planning around. The architecture is a genuine departure from the leader-and-region model that dominates geo-distributed systems, and the choice of QuePaxa is a bet that timeout-driven leader election is the wrong default on networks as hostile as the public Internet. Whether that bet extends past infrequently written control-plane data depends on numbers Cloudflare has not yet published.
Frequently Asked Questions
When is Meerkat the wrong tool for a workload?
Meerkat is a poor fit for write-heavy transactional workloads, such as database rows updated on every request. Every commit must wait for a round trip across a geographically dispersed majority, so p99 write latency can climb above 100 milliseconds and throughput becomes bounded by cross-region round-trip time rather than CPU or disk. For those workloads, region-pinned Raft or a clock-backed system like Spanner is likely cheaper.
How is QuePaxa different from Raft during a network partition?
QuePaxa is designed so that all replicas can accept writes at all times and the protocol never halts progress because of a timeout. That differs from Raft, where a leader election timeout is the only way to recover from a failed leader and where overly aggressive timeouts can depose a healthy one during a transient latency spike.
What operational costs come with a Meerkat deployment?
A cluster needs 2f + 1 replicas, each fully meshed with every other across Cloudflare’s edge. Control-plane bandwidth for the replicated log therefore scales with the number of replicas and their geographic spread, not just with application request volume. Operators also have to monitor quorum reachability and per-link round-trip time instead of simply watching whether a leader is alive.
Can a Meerkat client still fail even when the service is available?
Yes. The service as a whole stays available only when a majority of replicas can communicate and the client can reach one of them. A client pinned to a minority partition, or whose nearest replica has lost its path to the majority, will stall even though the rest of the cluster is healthy.
What would make Cloudflare rethink Meerkat’s design?
If production benchmarks show the cross-region write-latency tax is too high for even infrequently written control-plane state, or if log-replication bandwidth across hundreds of edge locations becomes the dominant cost, Cloudflare would likely fall back to region pinning or specialized timing hardware like Spanner’s TrueTime. Meerkat is currently a bet that availability matters more than write speed; measured numbers could change that bet.
