Strong consistency in global systems hinges on availability. Meerkat from Cloudflare offers leaderless consensus as a compromise between latency and fault tolerance.
In distributed systems with a global geography, classic consensus algorithms begin to degrade not due to logic, but due to the network. Approaches like Raft depend on a leader and timeouts. This means that only one node accepts entries while the others wait. In wide-area network conditions, this becomes a bottleneck: delays increase, the leader may become unavailable, and the system effectively halts until a new leader is elected. This is critical for control-plane services. A loss of availability even for a short interval disrupts coordination and exacerbates cascading failures.
Cloudflare encountered this limitation in its global network. The requirement was stringent: strong consistency with linearizable operations (linearizable reads/writes) and resilience to network fluctuations. Classic partially synchronous algorithms, such as Paxos or Raft, make progress only under predictable delays relative to timeouts. This assumption performs poorly in the real internet, where delays can change abruptly. As a result, there is an architectural conflict between consistency and availability.
The solution in Meerkat is a shift to leaderless consensus based on the QuePaxa algorithm. Unlike Raft, there is no single write point here. Any replica can accept write requests. This removes the dependency on a leader and reduces the risk of total unavailability in the event of its failure or network degradation. The key trade-off is an increase in the number of network rounds (round trips). To finalize an operation, one to three rounds of message exchanges with a majority of replicas are required. In the worst case, it could be more. This is the direct cost of abandoning a leader and achieving resilience to unpredictable delays.
From an architectural perspective, Meerkat is built around a globally replicable consensus log. The log consists of slots, each of which can contain an event. When a slot is “decided,” its value is fixed and the same across all replicas. The system’s invariant is simple but strict: if two replicas have made a decision on a slot, the values match. This guarantees a consistent order of operations and enables linearizable reads and writes. This approach makes the system suitable for control-plane tasks, such as a transactional key-value layer or leasing systems.
An interesting detail is that QuePaxa does not rely on timeouts for progress. This distinguishes it from most production consensus algorithms. The system continues to move forward even under “chaotic” message delays. This has been discussed in the industry for a long time, but there are almost no production implementations. Cloudflare claims that Meerkat could be the first implementation of this class on a global scale. So far, this has only been confirmed by a proof-of-concept with clusters of up to 50 replicas.
However, the leaderless model is not without its costs. The main issue is latency. Each additional round of communication increases the time to finalize an operation. In multi-region scenarios, consensus already adds significant delay. Estimates suggest that such overhead can reach 40–60% compared to local operations. QuePaxa attempts to optimize this balance, but the fundamental trade-off remains. Therefore, Meerkat is not positioned as a universal database. It is a specialized coordination layer where correctness and availability are prioritized over minimal latency.
The community’s reaction reflects this trade-off. Some engineers note the complexity of the model and question whether the additional round trips are justified in typical scenarios. This is a valid point. If the system operates in a predictable network, a leader-based approach may be simpler and faster. But in the context of global infrastructure with unstable delays, a leader becomes a risk rather than an optimization.
The conclusion here is pragmatic. Meerkat is not an attempt to replace Raft everywhere. It is an adaptation of consensus for a specific class of tasks: global coordination, where leader failures are unacceptable, and latency can be controlled. This approach aligns well with the trend towards specialized infrastructure primitives instead of universal solutions. Architects are increasingly choosing not “one algorithm for everything,” but a set of tools for different load and failure profiles.
If the abstraction is formulated correctly, developers higher up the stack will not see the complexity. They will see a stable control-plane with predictable behavior. But the price of this stability is a more complex internal model and careful handling of latency. This is the compromise that must be accepted in global systems.