Choose consensus for the failures your product must survive

A system can handle ordinary traffic comfortably and still leave users waiting when one link slows down. For a product that depends on shared configuration or leadership state, that waiting can matter more than peak throughput. Choose consensus around the failures the product must survive, then compare implementations against those requirements.

Cloudflare's Meerkat introduction, dated July 8, 2026, makes that trade-off concrete. It describes an experimental service, still in development, intended initially for small pieces of internal control-plane state. Its scope matters: this was an engineering account of an internal experiment, rather than a publicly available global database with a production availability promise.

Specify what continued progress means

Start with the operation that cannot wait. A configuration update and a customer transaction may both involve agreement between machines, but their business deadlines can differ. Write down which operation needs a current answer, who depends on it, and what the product should do while agreement is unavailable. A general requirement to be reliable leaves those decisions unresolved.

Then describe the communication that remains possible during failure. Cloudflare's stated requirements assume a live, mutually communicating majority and a client able to reach a machine connected to that majority. They also exclude actively malicious participants. Those conditions belong beside any availability claim. A disconnected client cannot benefit from a healthy majority it cannot reach, and tolerating crashes does not establish tolerance of Byzantine behavior.

For your own requirements, distinguish a failed machine from a machine that remains alive but responds slowly. Also distinguish a lost link from delays on one route while other routes remain usable. These cases can produce different waiting behavior. Treat them as separate questions during evaluation rather than assigning one broad label such as network failure to all of them.

Examine the waiting mechanism

Cloudflare motivates Meerkat through the stalls that can occur while a leader-based system waits for a timeout and replacement leader. A conservative timeout can avoid unnecessary leadership changes while extending the wait after a real problem. An aggressive timeout can react sooner while creating disruption when a slow leader is still functioning. That tension deserves attention before comparing headline throughput.

The underlying research predates the announcement. QuePaxa's paper belongs to SOSP 2023, held October 23–26. It presents a randomized asynchronous consensus approach with a fast path and hedging, intended to avoid depending on leader timeouts for progress. July 2026 is the Meerkat announcement date, not the invention date of QuePaxa.

The useful design question is whether your workload needs progress through slow-link conditions that an existing deployment handles poorly. That does not turn the paper into validation of your application. A protocol argument, a research prototype and an operated service answer different questions. Your application's storage, recovery process and client behavior still need their own evidence.

Evaluate the experience of waiting

A throughput result counts completed work under specified conditions. It cannot by itself tell you how long a user waits after a leader becomes unreachable. Ask for the distribution of completion times during the failure cases that matter to the product. Keep normal operation and recovery observations separate so that a strong ordinary result does not conceal a long interruption.

Interpret a request timeout carefully too. The caller may have stopped waiting without knowing whether the operation eventually took effect. A product specification should explain how the caller learns the outcome and whether another attempt is safe. Changing the consensus mechanism does not remove that application-level responsibility. Otherwise a faster internal recovery can still leave the customer facing an ambiguous result.

This is a proposed evaluation approach, not a claim that any particular implementation meets it. The necessary evidence would come from the chosen version and deployment under explicit conditions. Vendor descriptions and research results can guide that work, but neither supplies measurements for an untested product. Avoid turning their conclusions into an availability commitment in a customer contract.

The strongest case for staying with Raft

Established Raft tooling and a regional deployment may be the better engineering choice. A team can reasonably value familiar recovery procedures, available operational knowledge and a simpler network topology more than a different progress mechanism. If the product tolerates the observed interruption, replacing the consensus layer may add risk without addressing a business problem.

Regional placement can also narrow the requirement. If the product does not need globally distributed writes, asking it to solve that problem can make the architecture harder to operate. Document why a region is acceptable, including the failure it would expose. That makes the choice reviewable without pretending that every product has Cloudflare's network or control-plane needs.

The boundary changes when measured interruptions exceed the product's tolerance despite appropriate placement and operation. At that point, investigate alternatives against the same failure model. Keep migration effort and recovery ownership in the decision alongside latency. A less familiar system needs an operator who can explain how it returns to service when the happy path ends.

Put the requirement before the protocol

A useful decision record names the required operations, the surviving communication paths and the tolerated wait. It also states which faults are outside the promise. That record gives reviewers something concrete to challenge and gives future operators a reason for the architecture they inherit.

If your product needs shared state across services, AL+ offers custom software development. Bring the operations that must remain usable and the failures you need to withstand. Those requirements should shape the design before a protocol name becomes a commitment.