Raft con menos nodos: qué cambia en la práctica

Raft suele enseñarse con una idea simple: varios nodos, un líder, réplicas y una mayoría que decide. Esa versión funciona bien para explicar consistencia y tolerancia a fallos, pero también empuja una suposición que no siempre encaja con tu caso real: que más nodos siempre es mejor. En la práctica, cada nodo suma costo, latencia de coordinación, superficie operativa y más puntos que mantener sanos.

La propuesta de Raft con menos nodos abre una conversación más útil que la típica discusión académica sobre consenso. Si puedes lograr propiedades parecidas con un clúster más pequeño, entonces cambian varias cosas: cuánto pagas por infraestructura, qué tan rápido recuperas un nodo, cuántas réplicas necesitas para dormir tranquilo y qué nivel de riesgo aceptas cuando el sistema pierde miembros. No es un truco para “hacer magia” con menos máquinas; es un ajuste de diseño que te obliga a pensar mejor en el balance entre disponibilidad, costo y seguridad operacional.

Qué cambia cuando Raft deja de depender de una mayoría clásica

La versión tradicional de Raft está construida alrededor de una mayoría estricta. En un clúster de 5 nodos, por ejemplo, necesitas 3 para avanzar. Eso te da una tolerancia clara a fallos: puedes perder 2 nodos y seguir operando. En un clúster de 3 nodos, toleras 1 caída. Esa matemática es conocida, pero también cara si tu carga no justifica tantos replicas o si tu presupuesto está apretado.

La idea de usar menos nodos no significa eliminar la necesidad de consenso. Significa mover el punto de equilibrio. En vez de asumir que el sistema debe sobrevivir con una mayoría amplia, se exploran configuraciones donde el clúster es más pequeño o donde el conjunto decisor no es tan grande como en Raft clásico. Eso puede reducir costos y simplificar operaciones, pero también reduce el margen de error. Si pierdes un nodo en un clúster de 2, ya no tienes la misma red de seguridad que en uno de 5.

El costo real no es solo infraestructura

Cuando hablas de menos nodos, el ahorro obvio es el número de instancias. Pero hay otros costos menos visibles. Cada nodo adicional implica más monitoreo, más alertas, más tráfico entre réplicas, más tiempo en despliegues y más posibilidades de que una actualización falle a mitad del proceso. En equipos pequeños, eso pesa tanto como la factura mensual de la nube.

Piensa en un servicio interno de inventario que corre en 3 nodos en lugar de 5. Si cada nodo te cuesta 40 USD al mes, pasas de 200 USD a 120 USD, un ahorro de 80 USD mensuales. Eso parece menor, pero si tienes 20 servicios parecidos, ya estás hablando de 1.600 USD al mes. Para una startup en Ecuador, Colombia o Perú, ese número sí cambia decisiones.

Menos nodos, menos margen de maniobra

La otra cara es menos tolerancia a fallos. Con 3 nodos, puedes perder 1. Con 2 nodos, si uno cae, el sistema pierde capacidad de decidir. Eso no siempre es aceptable en producción. Si tu carga es crítica, como pagos o identidad, el ahorro puede salir caro. Si tu sistema es interno, tolera degradación temporal y tiene mecanismos de reintento, la evaluación cambia.

La pregunta correcta no es si menos nodos es mejor. La pregunta es qué estás comprando con cada nodo extra. Si el nodo adicional solo existe para cumplir una regla de diseño heredada, quizá estés pagando una prima innecesaria. Si ese nodo adicional evita una caída de servicio en un momento de alto tráfico, entonces sí tiene sentido.

La matemática de la tolerancia a fallos no perdona

En consenso distribuido, la disponibilidad no se mide por intuición. Se mide con números. La regla clásica de mayoría te da una relación clara entre tamaño del clúster y fallos tolerados. Un clúster de 1 nodo no tolera nada. Uno de 3 tolera 1 fallo. Uno de 5 tolera 2. Y así sucesivamente. El problema es que el costo crece con cada nodo, pero el beneficio no crece linealmente para todos los casos.

Si tu objetivo es solo evitar corrupción de datos y mantener un líder estable, un clúster pequeño puede ser suficiente. Si tu objetivo es sobrevivir a fallos simultáneos, mantenimiento, particiones de red y actualizaciones, el tamaño importa mucho más. La diferencia entre 3 y 5 nodos no es cosmética. Es el salto entre perder 1 nodo y seguir, o perder 2 nodos y seguir. En la operación diaria, eso puede ser la diferencia entre un incidente menor y una caída total.

Ejemplo práctico con tres escenarios

Supón que administras un servicio de metadatos para una plataforma de e-learning. Tu SLA interno no promete 99.99%, pero sí continuidad razonable durante el horario laboral. Puedes pensar en tres opciones:

1. 1 nodo: barato, simple, pero sin tolerancia real a fallos. Si cae, te quedas fuera.
2. 3 nodos: toleras 1 fallo, mantienes consenso con una mayoría pequeña y el costo sigue siendo moderado.
3. 5 nodos: toleras 2 fallos, pero pagas más en infraestructura y complejidad operativa.

Si el servicio soporta reintentos y no es el punto de entrada al negocio, 3 nodos puede ser suficiente. Si procesa órdenes o estados financieros, probablemente 5 nodos te da una protección más razonable.

Tabla comparativa simple

La tabla no pretende ser una regla universal, porque el costo real depende de CPU, red, almacenamiento y tipo de carga. Pero sí te sirve para visualizar algo básico: cada nodo extra compra resiliencia, no solo capacidad. Si tu sistema no necesita esa resiliencia adicional, el gasto puede estar sobredimensionado.

Lo que gana tu operación cuando bajas el número de nodos

Reducir el tamaño del clúster puede mejorar varias cosas al mismo tiempo. Primero, la coordinación entre nodos suele ser más simple. Menos miembros significa menos heartbeats, menos elecciones de líder y menos tráfico de replicación. Segundo, los despliegues y upgrades se vuelven más manejables. Tercero, el monitoreo se simplifica porque tienes menos componentes que observar y menos combinaciones de fallo que diagnosticar.

En entornos donde el equipo de plataforma es pequeño, esto importa mucho. No siempre tienes un SRE dedicado por servicio. A veces una sola persona lleva Kubernetes, bases de datos, colas y observabilidad. En ese contexto, reducir nodos no solo baja costos de nube; también baja fricción humana. Y esa fricción humana suele ser el cuello de botella real.

Menos nodos también puede significar menos latencia de coordinación

Raft necesita replicar entradas de log y confirmar compromiso. Si tienes menos nodos, la ruta de confirmación puede ser más corta. Eso no garantiza menor latencia en todos los casos, porque influyen red, disco y carga, pero sí reduce el número de participantes en el protocolo. En sistemas sensibles a tiempo de respuesta, eso puede ayudar.

Ahora bien, no confundas menos nodos con más velocidad automática. Un clúster pequeño puede volverse un cuello de botella si la carga crece. Si tu tasa de escrituras aumenta de forma sostenida, el ahorro inicial puede desaparecer cuando el líder tenga que manejar demasiadas confirmaciones o cuando el disco empiece a saturarse.

Menos nodos no resuelve problemas de diseño

Si tu aplicación ya tiene una mala estrategia de reintentos, un esquema de escritura inconsistente o dependencias externas frágiles, bajar nodos no arregla nada. Solo hace el sistema más barato de operar. El riesgo es que te emociones con la simplicidad y luego descubras que el problema estaba en la arquitectura, no en el número de réplicas.

Por eso conviene medir antes de cambiar. Revisa métricas como latencia p95, tasa de elecciones de líder, tiempo de recuperación tras caída, uso de disco y comportamiento ante particiones de red. Si no tienes números, estás decidiendo a ciegas.

Cuándo tiene sentido una variante más liviana

No todos los sistemas necesitan la misma defensa. Un catálogo interno, un servicio de feature flags o un índice de búsqueda secundario no tienen el mismo nivel de criticidad que un ledger financiero. Ahí es donde una variante con menos nodos puede tener sentido. Si el costo de una caída breve es bajo y el dato puede reconstruirse o sincronizarse después, el diseño más liviano puede ser suficiente.

También hay casos donde el entorno limita el tamaño del clúster. En edge computing, sucursales remotas o despliegues en regiones con conectividad variable, mantener 5 nodos siempre disponibles puede ser irrealista. Un clúster más pequeño, bien monitoreado, puede darte una solución operable donde una implementación clásica sería demasiado pesada.

Casos donde sí lo consideraría

• Servicios internos con baja criticidad y alto costo por nodo.
• Productos en etapa temprana que todavía están validando carga real.
• Despliegues en regiones con presupuesto ajustado, como equipos pequeños en LatAm.
• Sistemas que priorizan simplicidad operativa sobre tolerancia extrema a fallos.

Casos donde no lo haría

• Sistemas de pagos, identidad o autorización.
• Bases de datos de fuente de verdad para transacciones críticas.
• Plataformas con requisitos de alta disponibilidad medidos en cuatro o cinco nueves.
• Entornos donde una caída de 10 minutos genera pérdidas mayores que el ahorro mensual.

Si dudas, usa una regla simple: si el impacto del downtime supera de forma clara el costo de un nodo extra, no recortes. Si el servicio puede degradarse sin afectar ingresos o seguridad, la variante liviana puede ser razonable.

Qué debes revisar antes de mover producción

Antes de pasar de 5 nodos a 3, o de 3 a una configuración más ajustada, necesitas revisar varias cosas. No basta con apagar instancias y esperar que todo siga igual. En sistemas distribuidos, los detalles importan demasiado.

1. Quórum real: confirma cuántos nodos necesitas para mantener decisiones válidas.
2. Patrón de fallos: revisa si tus fallos suelen ser aislados o simultáneos.
3. RPO y RTO: define cuánto dato puedes perder y en cuánto tiempo debes volver.
4. Capacidad por nodo: asegúrate de que cada nodo aguante más carga si reduces el clúster.
5. Red y disco: valida que el líder no quede saturado por replicación o fsync.
6. Operación: calcula el tiempo humano que ahorras al administrar menos máquinas.

Si trabajas con Kubernetes o con VMs administradas por Terraform, también vale la pena revisar el proceso de reemplazo de nodos. A veces el problema no es el consenso, sino el tiempo que tardas en recrear un miembro sano. Un clúster pequeño puede degradarse más rápido si el autoscaling o la recuperación están mal afinados.

Herramientas y referencias útiles

Si quieres revisar la base conceptual, la documentación oficial de Raft sigue siendo el punto de partida de referencia para entender el protocolo: https://raft.github.io/

Si tu implementación corre sobre un motor concreto, conviene leer su documentación de consenso. Por ejemplo, etcd documenta su arquitectura de almacenamiento distribuido y su uso de Raft aquí: https://etcd.io/docs/

Y si tu foco está en diseño de sistemas distribuidos a nivel general, la guía de Google sobre sistemas distribuidos sigue siendo una lectura útil para pensar en fallos, latencia y consistencia: https://research.google/pubs/pub40801/

Tabla resumen

La discusión sobre Raft con menos nodos no va de buscar atajos. Va de entender cuánto te cuesta cada nivel de seguridad que agregas. En muchos equipos, el diseño por defecto se hereda sin revisar. Y ahí es donde aparecen clústeres sobredimensionados, facturas innecesarias y operaciones más pesadas de lo que deberían ser.

Si tu sistema puede vivir con menos nodos sin romper sus objetivos, ese cambio tiene sentido. Si no, la mayoría clásica sigue siendo una apuesta sólida. Lo importante es que decidas con números, no por inercia.