En 2020, un switch de red de Cloudflare empezó a fallar a medias y un sistema apoyado en consenso se degradó tanto que el dashboard funcionó 80 veces más lento de lo normal durante seis horas. No se perdió ni un dato, pero las escrituras quedaron bloqueadas hasta arreglar la red. Esa es la lección de la que parte Meerkat, el servicio de consenso experimental con el que Cloudflare gestiona su plano de control global, y la razón de que no use Raft ni Paxos, sino QuePaxa, un algoritmo académico de 2023 casi sin uso en producción.
El equipo lo explica en un artículo publicado el 11 de noviembre de 2026. Merece la pena leerlo aunque nunca vayas a implementar un protocolo de consenso, porque cualquiera que opere etcd, Consul o ZooKeeper vive con los mismos compromisos.
El problema: el líder y el detector de fallos
Raft, Multi-Paxos y Viewstamped Replication funcionan igual en lo esencial: un único líder propone, y así se evita que varios proponentes se bloqueen entre sí (lo que el artículo llama interferencia destructiva). Mientras el líder está sano y la red se porta bien, deciden en un solo viaje de ida y vuelta.
El precio es que todo depende de ese líder. Si cae, va lento o se queda aislado, el sistema se para hasta elegir otro, y para eso las réplicas tienen que adivinar que ha fallado. En una red de área amplia, un servidor caído y un mensaje que llega tarde son indistinguibles. Cloudflare señala dos efectos:
- Falsos positivos. Un pico de latencia de dos segundos hace parecer muerto al líder, se convocan elecciones y los candidatos compiten por la mayoría y se bloquean entre ellos. Es un fallo metaestable: la red se recupera en dos segundos, pero las elecciones pueden seguir mucho más tiempo.
- Lentitud incluso acertando. El timeout de elección no puede bajar de la latencia de red. Con viajes de cientos de milisegundos entre continentes, detectar un líder caído cuesta del orden de un segundo, y durante ese tiempo no hay escrituras.
La documentación de etcd lo confirma con números: el election timeout por defecto es de 1.000 ms y debe ser al menos 10 veces el RTT entre miembros, con un máximo de 50 s pensado para clústeres repartidos por el mundo.
La solución: un líder opcional que no hace falta detectar
QuePaxa (Tennage, Băsescu et al., 2023) cambia tres cosas:
- Los proponentes cooperan en lugar de competir. Cada propuesta lleva una prioridad aleatoria; cuando un proponente ve otra con más prioridad, la adopta y la difunde como suya. Nadie puede bloquear indefinidamente a otro.
- El líder es opcional. Tiene la prioridad máxima y es el único que puede decidir en un viaje de ida y vuelta, pero cualquier réplica puede proponer. Si cae, el resto sigue.
- No hay detector de fallos. Los clientes envían la petición a todas las réplicas y las que no son líder esperan un pequeño hedge timeout antes de proponer, para dar ventaja al líder. Ese timeout no detecta nada, así que no depende de la latencia: en Raft, un timeout de 5 ms con 100 ms de latencia congelaría el sistema; en QuePaxa solo añade proponentes.
Cada ronda tiene cuatro fases: proponer y adoptar (aquí está el camino rápido del líder), difundir, comprobar y decidir, y arrastrar la mejor propuesta a la siguiente ronda. La seguridad sale de la intersección de mayorías: dos mayorías de réplicas siempre comparten al menos una, así que si el líder llegó primero a una mayoría, nadie puede decidir otra cosa. En la implementación de Cloudflare, escrita en Rust, el hedge timeout lo esperan los clientes y no las réplicas, para mandar menos mensajes.
| Raft (etcd) | QuePaxa (Meerkat) | |
|---|---|---|
| Quién propone | Solo el líder | Cualquier réplica; el líder tiene prioridad |
| Si cae el líder | Detectar el fallo y elegir otro; sin escrituras mientras tanto | Siguen decidiendo las demás, más despacio |
| Timeout clave | Elección, ≥ 10 × RTT (1.000 ms por defecto en etcd) | Hedge local, sin relación con el RTT |
| Coste en el caso feliz | 1 viaje de ida y vuelta | 1 viaje si decide el líder |
| Madurez | Décadas en producción | Paper de 2023, en verificación formal |
Los resultados
En las pruebas de Meerkat, con servidores en casi todos los continentes, más del 95 % de las decisiones las toma el líder en la primera fase. Cuando no, el rendimiento cae como mucho a un tercio durante unos instantes, porque hacen falta tres fases en lugar de una. Con el líder caído, la tasa de decisiones baja a alrededor del 65 % y vuelve al 100 % al sustituirlo, un minuto después; según Cloudflare, el sistema nunca se ha detenido del todo. Además, pueden cambiar qué réplica hace de líder con el clúster en marcha.
El precio también está claro: cuanto más bajo el hedge timeout, más proponentes activos, más ancho de banda y más rondas fallidas. Cloudflare elige pagar red a cambio de no quedarse sin escrituras.
Qué se puede aprender
La lección general no es "cambia Raft por QuePaxa", sino que un timeout que detecta fallos es una apuesta sobre la red, y en redes de área amplia esa apuesta se pierde a menudo. Si operas etcd o Consul estirado entre regiones, el artículo explica por qué los ajustes conservadores de elección no son pereza: un timeout agresivo convierte cada pico de latencia en una elección, y una elección fallida puede alimentar la siguiente.
También es un buen ejemplo de cómo llevar investigación a producción: Cloudflare parte de un incidente real con cifras, elige el protocolo por las propiedades que necesita y no por su popularidad, y asume el riesgo con verificación formal, simulación e inyección de fallos.
Qué no es trasladable
Meerkat es experimental, de uso interno y sin código publicado. QuePaxa no tiene la batería de implementaciones probadas de Raft, y Cloudflare está ampliando el diseño original, que solo contempla réplicas que caen y no vuelven, para que admita recuperación tras un fallo; por eso lo están verificando formalmente. Si tu clúster vive en una sola región con latencias de milisegundos, los problemas que resuelve QuePaxa apenas te afectan y Raft sigue siendo la opción sensata.
Fuentes
- Choosing QuePaxa, an unusual consensus algorithm (Cloudflare, 11 de noviembre de 2026)
- QuePaxa: Escaping the Tyranny of Timeouts in Consensus (SOSP 2023)
- etcd: Tuning