Cloudflare apuesta por QuePaxa: consenso sin líder

En 2020, el fallo parcial de un switch central de la red de Cloudflare dejó su panel de control operando 80 veces más lento durante seis horas. No se perdió ni un dato, pero el sistema quedó inutilizado para escrituras hasta que el problema se resolvió. Ese episodio explica por qué la compañía decidió construir su nuevo servicio interno de consenso, Meerkat, sobre un algoritmo poco convencional: QuePaxa.

¿Por qué el consenso distribuido se rompe en redes globales?

Un algoritmo de consenso permite que un grupo de máquinas acuerde un único valor compartido aunque algunas fallen o se desconecten. La garantía clave es que nunca decidan valores contradictorios: por eso Meerkat puede construir un log ordenado de eventos y ofrecer aplicaciones como un almacén clave-valor donde todas las réplicas ven el mismo estado.

El problema aparece cuando ese consenso tiene que correr sobre Internet y no dentro de un datacenter. La mayoría de los sistemas en producción usan algoritmos maduros como Raft, (Multi-)Paxos o Viewstamped Replication, los mismos que hay detrás de herramientas conocidas como Consul, etcd o Apache ZooKeeper. Están probados, tienen implementaciones estables y funcionan bien en redes locales.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Pero la red de Cloudflare no es local: según SDxCentral, la compañía opera más de 330 centros de datos y Meerkat replica estado entre continentes. Ahí la latencia deja de ser predecible y los supuestos de esos algoritmos empiezan a fallar.

El problema no es el líder: es la interferencia destructiva

Casi todos los algoritmos de consenso desplegados centralizan las propuestas en un líder para evitar que varios nodos compitan. El líder ordena las peticiones concurrentes, permite decidir en un solo viaje de red y hace que el sistema sea rápido… mientras esté sano y sea alcanzable.

El costo aparece cuando el líder se cae, se desconecta o simplemente responde más lento. El sistema se detiene y la única salida es elegir un reemplazo. Y ahí vuelve el problema original: en Raft, cualquier réplica que sospeche que el líder falló puede postularse y pedir votos. Si varias lo hacen a la vez, se bloquean mutuamente compitiendo por la mayoría, exactamente la interferencia destructiva que Paxos intentaba evitar.

Cloudflare lo describe como un fallo metaestable: un patrón que se perpetúa aunque la causa inicial desaparezca. Una caída de red de dos segundos —o un switch momentáneamente defectuoso— alcanza para forzar una elección, que puede fallar, y disparar nuevas elecciones mucho después de que la red ya se recuperó.

El segundo ingrediente es la detección de fallos. En una red asíncrona nadie puede observar directamente si una máquina remota murió: solo se ve que un mensaje esperado no llegó. El detector tiene que adivinar, y a veces adivina mal. Por eso Raft se despliega con timeouts de elección de cinco a diez veces el round-trip time de la red. Con latencias transcontinentales de cientos de milisegundos, detectar un coordinador caído puede tardar alrededor de un segundo, y hasta que el detector reacciona el sistema está abajo.

¿Qué hace QuePaxa distinto de Raft o Paxos?

QuePaxa fue publicado en 2023 por Tennage & Băsescu et al. y parte de una pregunta incómoda: ¿y si el sistema no necesitara detectar fallos ni depender de un líder para progresar? Sus tres decisiones de diseño apuntan justamente a eso.

Líder opcional. Existe un líder y es el único que puede decidir en un solo viaje de red, pero si se cae, cualquier otro proponente puede seguir proponiendo. No hay elecciones que bloqueen el sistema.
Cero detección de fallos. En lugar de reaccionar a una falla, los clientes apuestan doble: envían la petición a todas las réplicas y las que no son líder esperan un pequeño hedge timeout para darle al líder la chance de decidir solo. Ese timeout no depende de la latencia de la red, es local y puede ser tan chico como se quiera.
Interferencia constructiva. Los proponentes no compiten: cooperan. Cada propuesta lleva una prioridad aleatoria y, cuando un proponente recibe una de prioridad mayor, la adopta como propia. Eso hace que el conjunto converja hacia la propuesta de mayor prioridad en lugar de bloquearse.

Las cuatro fases: así decide QuePaxa en una ronda

QuePaxa trabaja en rondas de cuatro fases. En la fase 0 los proponentes sortean una prioridad y adoptan la propuesta de mayor prioridad que reciban de la mayoría. Si es la primera ronda y el líder sabe que su propuesta llegó primero a una mayoría de recorders, decide de inmediato. En la fase 1 los proponentes difunden lo adoptado; en la fase 2 preguntan si apareció algo de mayor prioridad y deciden si la respuesta coincide con lo propio; y en la fase 3 los que no decidieron adoptan la mejor propuesta que ven para arrancar la ronda siguiente sin perder lo aprendido.

La garantía detrás de todo esto es la intersección de mayorías: dos mayorías de recorders siempre comparten al menos un nodo, así que ninguna decisión puede contradecir a otra. El paper estima que cada ronda tiene un 50% de probabilidad de decidir, pero en la práctica esa probabilidad es bastante mayor gracias a la adopción de propuestas entre rondas.

¿Qué resultados reportó Cloudflare?

En sus evaluaciones con servidores repartidos por casi todos los continentes, Cloudflare reportó que Meerkat sigue procesando peticiones incluso cuando el líder se cae, se desconecta o se vuelve lento, y que nunca lo vio detenerse por completo. Hasta un 95% de las decisiones las toma el líder en la primera fase, lo que mantiene el throughput estable; cuando eso no ocurre, el rendimiento cae como máximo a un tercio del habitual, señal de que hicieron falta tres fases en vez de una.

El costo que sí es inevitable: según SDxCentral, Cloudflare corrió varias pruebas de concepto con hasta 50 réplicas distribuidas globalmente en las que el líder falla repetidamente y el clúster sigue operando sin subir la tasa de errores. La misma publicación aclara dos límites importantes para cualquiera que quiera adoptarlo: Meerkat todavía no está en producción, seguirá siendo un servicio solo interno por ahora, y no fue diseñado para construir bases de datos de propósito general.

¿Qué significa esto para tu startup?

No vas a desplegar QuePaxa mañana. Pero el razonamiento de Cloudflare aplica a cualquier equipo que opere infraestructura multi-región, y ahí hay decisiones concretas que puedes tomar hoy.

Audita tus timeouts antes de crecer geográficamente. Si usas etcd, Consul o un sistema basado en Raft, revisa con qué margen está configurado el election timeout. La regla conservadora de cinco a diez veces el round-trip time es sensata en una red local y muy costosa cuando tus réplicas están en tres continentes: cada falla de detección se traduce en segundos de bloqueo total.
Separa el plano de control del plano de datos. El consenso distribuido es caro por definición, porque la latencia de decisión es proporcional a la distancia entre la mayoría de tus réplicas. Si tu base de datos principal no necesita consistencia fuerte entre regiones, no pagues ese precio: reserva el consenso para coordinar configuración, leases y estado crítico.
Mide la degradación, no solo el uptime. El incidente de 2020 en Cloudflare no fue una caída: fue un sistema que siguió vivo pero operando 80 veces más lento. Instrumenta métricas de rendimiento degradado y define a partir de qué umbral consideras que el servicio está inutilizable para tus usuarios.
Desconfía de los sistemas que se detienen por completo. Si un fallo de red transitorio puede dejar tu plataforma sin escrituras, tienes un punto único de fallo disfrazado de alta disponibilidad. Probar el comportamiento bajo latencia real —no solo bajo caída de nodos— es la forma más honesta de saberlo.

Lo que todavía no está resuelto

Cloudflare es explícito sobre el riesgo de elegir un algoritmo menos transitado: QuePaxa no está tan probado en batalla como Raft o Paxos, y el equipo está extendiendo el diseño original —pensado para fallos definitivos— para soportar recuperación tras caídas. Por eso están verificando formalmente su implementación en Rust, además de correr simulaciones e inyección de fallos.

Para el ecosistema emprendedor, la lección no es copiar el algoritmo sino el criterio: cuando la sabiduría convencional no encaja con tus restricciones reales de red, conviene volver a la investigación académica antes que forzar un diseño que no aplica. Cloudflare tardó seis horas de degradación en 2020 en aprenderlo.

No se encontraron datos adicionales verificables sobre fechas de lanzamiento público o disponibilidad general de Meerkat más allá de lo publicado por la compañía y por SDxCentral.