Escalado horizontal y vertical: qué son, cuándo usar cada uno

Cuando tu sistema se queda corto —más usuarios, más carga, más lentitud— la pregunta es: ¿escalamos la máquina que tenemos o añadimos más máquinas? Esa diferencia define el escalado vertical (scale up) y el escalado horizontal (scale out). No son intercambiables: cada uno resuelve problemas distintos y tiene ventajas y límites propios.

En este artículo explico qué es cada uno, cómo saber cuál aplicar, sus ventajas y desventajas, y cuándo combinar ambos.

¿Qué es el escalado vertical (scale up)?

Escalar verticalmente significa aumentar los recursos de la misma máquina: más CPU, más RAM, más disco. La aplicación sigue corriendo en un solo servidor (o en el mismo nodo); ese servidor simplemente es más potente.

Ejemplos:

Pasar de una instancia con 2 vCPU y 4 GB RAM a una con 8 vCPU y 32 GB RAM.
Añadir más memoria a un servidor de base de datos.
Subir el tier de tu instancia en AWS, GCP o Azure (por ejemplo de t3.medium a t3.xlarge).

Analogía: Es como cambiar el motor de un coche por uno más potente. Sigue siendo un solo coche, pero con más capacidad.

¿Qué es el escalado horizontal (scale out)?

Escalar horizontalmente significa añadir más máquinas (o instancias) que hacen el mismo trabajo. La carga se reparte entre varias: load balancer, más réplicas de la aplicación, más nodos en un clúster. No cambias el tamaño de cada máquina; cambias la cantidad.

Ejemplos:

Pasar de 1 a 4 instancias de tu API detrás de un load balancer.
Añadir más réplicas de un servicio en Kubernetes.
Añadir nodos a un clúster de bases de datos (réplicas de lectura, sharding).
Más workers consumiendo de la misma cola.

Analogía: Es como poner más coches en la carretera en lugar de hacer un solo coche más grande. Más unidades, misma capacidad por unidad.

Ventajas y desventajas

Escalado vertical

Ventajas:

Implementación simple: no tocas la arquitectura. Cambias el tamaño de la instancia y reinicias (o redimensionas en caliente si el proveedor lo permite).
Sin cambios de código en muchos casos: la app sigue siendo un solo proceso, una sola base de datos, sin lógica de distribución.
Menos piezas que operar: un solo servidor (o un solo nodo principal) en lugar de varios. Menos red, menos coordinación.
Útil para cuellos de botella puntuales: si el límite es CPU o RAM en una sola máquina, subir de tamaño puede resolverlo rápido.
Coste inicial bajo en términos de diseño: no necesitas load balancer, sesiones distribuidas ni replicación de datos para empezar.

Desventajas:

Límite físico: en algún momento la máquina más grande del proveedor no da más de sí. No puedes escalar verticalmente para siempre.
Punto único de fallo: si esa máquina cae, cae todo el servicio (salvo que tengas redundancia por otros medios).
Precio no lineal: las instancias muy grandes suelen ser proporcionalmente más caras. Duplicar CPU/RAM no suele costar el doble, sino más.
No mejora la resiliencia por sí solo: un reinicio, un mantenimiento o un fallo de hardware afecta al 100 % del tráfico que atiende esa máquina.
No escala infinitamente: hay un techo por máquina (y por región/proveedor).

Escalado horizontal

Ventajas:

Escala teóricamente sin límite: puedes añadir más y más instancias (dentro de lo que permita tu diseño y tu bolsillo).
Resiliencia: si una instancia cae, las demás siguen sirviendo. El load balancer deja de enviar tráfico a la caída.
Flexibilidad de carga: puedes añadir o quitar instancias según tráfico (autoescalado). De día más instancias, de noche menos.
Coste más predecible por unidad: muchas instancias pequeñas suelen escalar de forma más lineal que una sola gigante.
Permite alta disponibilidad y despliegues sin downtime (rotar instancias una a una).

Desventajas:

Arquitectura más compleja: necesitas load balancer, gestión de sesiones (o sesiones stateless), posiblemente caché distribuido, replicación de datos.
Estado compartido es el enemigo: si tu app guarda estado en memoria (sesiones, colas en RAM), repartir tráfico entre varias máquinas obliga a externalizar ese estado (Redis, BD, etc.).
Más piezas que operar: más servidores, más red, más configuración, más monitorización.
No arregla cuellos de botella en un solo punto: si el límite es una base de datos central que no escala, añadir 10 instancias de API no lo soluciona; hay que escalar (o distribuir) también la BD.
Coste de coordinación: consistencia, transacciones distribuidas, líderes y réplicas añaden complejidad y posibles fallos.

¿Cómo saber cuál hacer?

No es “vertical malo, horizontal bueno”. Depende del problema que tengas y del momento en que estés.

Elige escalado vertical cuando…

El cuello de botella es claramente CPU o RAM en una sola máquina y no has llegado al límite del proveedor. Ejemplo: un proceso que usa el 100 % de la CPU en una instancia pequeña.
Tu aplicación no está preparada para correr en varias instancias: tiene estado en memoria, sesiones locales, o asume “una sola instancia”. Escalar verticalmente te da aire mientras preparas la app para horizontal.
Necesitas una solución rápida y no tienes tiempo (o presupuesto) para introducir load balancer, stateless y réplicas. Subir de instancia puede ser algo temporal.
La carga es estable y no tienes picos enormes. Una máquina más grande puede ser más simple de operar que un clúster.
Es una base de datos o un componente que no repartes aún: a veces el primer paso es darle más recursos al nodo existente antes de montar réplicas o sharding.

Elige escalado horizontal cuando…

Necesitas más capacidad y ya estás en una instancia grande, o no quieres depender de una sola máquina.
Quieres alta disponibilidad: si una instancia cae, el resto debe seguir sirviendo.
La carga es variable (picos, horarios, campañas) y quieres autoescalar: añadir y quitar instancias según demanda.
Tu aplicación es (o puede ser) stateless: sin estado en memoria por instancia, o con estado en Redis/BD. Entonces repartir tráfico entre varias instancias es natural.
El límite es cantidad de requests o conexiones, no el poder de una sola CPU. Más instancias reparten la carga.

Combina ambos cuando…

Vertical para el componente que es el cuello de botella (por ejemplo, la base de datos): primero dale más recursos al nodo.
Horizontal para la capa de aplicación (APIs, workers): varias instancias detrás de un load balancer.
Vertical como parche rápido; horizontal como estrategia a medio plazo una vez la app esté preparada.

Resumen práctico

Criterio	Escalado vertical	Escalado horizontal
Qué cambias	Tamaño de la máquina	Número de máquinas
Complejidad	Baja	Alta
Límite	Techo de la máquina	Diseño y coste
Resiliencia	No mejora por sí solo	Alta disponibilidad
Estado en memoria	No problemático	Hay que externalizarlo
Cuándo usarlo	Cuello de botella CPU/RAM, solución rápida	Más capacidad, HA, carga variable

Mi perspectiva personal

Empezar por escalado vertical suele ser razonable: subir de instancia es rápido y no obliga a rediseñar la aplicación. Pero en cuanto esperas crecimiento, picos de tráfico o no quieres un solo punto de fallo, escalar horizontalmente pasa a ser la apuesta correcta. Eso implica diseñar (o refactorizar) hacia stateless, externalizar sesiones y estado, y tener load balancer y réplicas. El esfuerzo es mayor, pero el techo y la resiliencia cambian.

He visto equipos quedarse solo en vertical hasta topar con el límite de la instancia más grande y tener que rediseñar con prisas. Y también equipos que montan clúster horizontal sin haber resuelto antes el cuello de botella real (por ejemplo, una BD que no escala), y entonces añadir más instancias de API no mejora nada. La clave es medir el cuello de botella, decidir si lo alivias con más recursos en un nodo (vertical) o con más nodos (horizontal), y en paralelo ir preparando la aplicación para horizontal cuando sea el camino que quieras seguir.

En resumen: vertical para ganar tiempo y resolver límites puntuales; horizontal para capacidad y resiliencia a largo plazo. Saber qué es cada uno y cuándo aplicarlo evita optimizar en la dirección equivocada.