Escalado vertical vs. horizontal — ¿cuáles son los límites reales de cada uno?

#Los dos ejes del escalado

Todo sistema que se queda pequeño en su primer servidor tiene exactamente dos palancas para tirar: hacer que ese servidor sea más grande (escalado vertical, o "scale up"), o añadir más servidores y repartir la carga entre ellos (escalado horizontal, o "scale out"). Los entrevistadores hacen esta pregunta no porque las definiciones sean difíciles, sino porque quieren ver si entiendes dónde se rompe realmente cada enfoque — los modos de falla solo aparecen cuando superas el 80% fácil del problema.

#Escalado vertical: simple hasta que deja de serlo

Escalar verticalmente significa añadir más CPU, más RAM, discos más rápidos o una interfaz de red más veloz a una sola máquina. Su mayor atractivo es que no cambia nada en tu aplicación: no hay transacciones distribuidas, ni fallos parciales, ni particiones de red que razonar. Una base de datos relacional de un solo nodo con más RAM simplemente cachea más del working set; un servicio de un solo nodo con más núcleos simplemente atiende más peticiones concurrentes, hasta el límite de su thread pool y su capacidad de I/O.

Los límites reales son:

• Un techo de hardware. Incluso las instancias más grandes de la nube tienen un tope de vCPUs y de RAM. Puedes pedir una máquina más grande hasta que ya no puedes — y en ese punto el escalado vertical simplemente se acaba, y no tienes plan B si no lo construiste antes.
• Un costo no lineal. El cómputo en el extremo alto del catálogo de instancias cuesta desproporcionadamente más por unidad de capacidad que las instancias de gama media. Duplicar el tamaño de tu instancia rara vez duplica tu factura — casi siempre la más que duplica.
• Un punto único de falla. Una máquina es una máquina. Si muere, se reinicia, o la plataforma subyacente la reprograma, todo el servicio cae con ella, a menos que ya la hayas emparejado con una réplica en espera — momento en el que, sin darte cuenta, introdujiste buena parte de la complejidad del escalado horizontal de todas formas.
• Tiempo de inactividad al actualizar. Redimensionar una instancia en ejecución normalmente exige un ciclo de parada/arranque (o como mínimo un failover a una réplica), así que los eventos de escalado vertical rara vez son tan invisibles para el usuario como añadir un décimo nodo detrás de un balanceador.
• Rendimientos decrecientes dentro de la propia máquina. Pasado cierto número de núcleos, la contención de locks, la saturación del bus de memoria y el tráfico de coherencia de caché entre núcleos hacen que el núcleo 65 no aporte el mismo throughput que aportó el segundo — es el mismo fenómeno que describe la Ley de Amdahl, solo que ocurre dentro de un chip en vez de a través de un clúster.

#Escalado horizontal: sin techo, pero con otra factura pendiente

Escalar horizontalmente significa correr la misma carga de trabajo en muchas máquinas detrás de un balanceador. Su atractivo es el opuesto del vertical: no hay techo teórico (en principio puedes seguir añadiendo nodos indefinidamente), el costo escala de forma casi lineal, y la tolerancia a fallos viene gratis — si un nodo muere, los demás absorben su tráfico.

Sus límites reales tienen menos que ver con el hardware y más con el diseño de tu aplicación:

• La ausencia de estado es un requisito, no un lujo. Si una petición puede llegar a cualquier nodo, ningún nodo puede ser el único lugar que recuerda la sesión de un usuario, una subida en progreso o una conexión WebSocket — ese estado tiene que moverse a algo compartido (Redis, una base de datos, enrutamiento sticky con sus propias contrapartidas) antes de que el escalado horizontal te aporte algo.
• La consistencia de datos se complica. En el momento en que tienes más de un nodo que puede aceptar una escritura sobre el mismo dato lógico, estás haciendo sistemas distribuidos: el lag de replicación, los escenarios de split-brain y la disyuntiva del teorema CAP entre consistencia y disponibilidad durante una partición de red dejan de ser cosas académicas.
• La coordinación crece con el clúster. El service discovery, los health checks, el consenso para elegir un líder y la invalidación de caché entre nodos cuestan algo, y ese costo crece a medida que añades más nodos — es la penalización de contención y coherencia que describe la Ley Universal de Escalabilidad, y es la razón por la que duplicar el número de nodos rara vez duplica el throughput pasado cierto punto.
• La latencia de red entre nodos entra al camino crítico de una forma que nunca ocurría dentro de una sola máquina, donde la comunicación entre hilos era un acceso a memoria, no un round trip por red.

#Por qué los sistemas reales usan ambos

En producción, "vertical vs. horizontal" es una falsa dicotomía. La forma típica es: una capa de aplicación sin estado que escala horizontalmente detrás de un balanceador (barato añadir nodos, no hay datos que sincronizar), delante de una capa de datos que se escala verticalmente hasta donde sea razonable (una instancia de base de datos primaria más grande) antes de recurrir a técnicas horizontales — réplicas de lectura, sharding — porque particionar correctamente una base de datos relacional es un orden de magnitud más difícil que añadir un décimo servidor web sin estado.

🧠 Check your understanding
0/2 · 0/2 answered
1. Un primario de PostgreSQL de un solo nodo se está quedando sin margen bajo carga de escritura. ¿Cuál es el PRIMER límite que deberías sospechar antes de recurrir al sharding?
El desbalance del anillo de hashing consistenteEl teorema CAPLa latencia del DNS round robinEl techo duro del tamaño de instancia más grande disponible en CPU, RAM e IOPS
2. ¿Por qué una aplicación web con estado que depende de afinidad de sesión no puede escalar horizontalmente sin cambios?
Un balanceador puede enrutar una petición nueva a cualquier nodo, así que ningún nodo puede ser el único que guarda el estado de sesiónHTTP es un protocolo sin estado y prohíbe usar varios servidoresEl escalado horizontal exige por definición una base de datos NoSQLLas conexiones TCP no se pueden balancear