Escalabilidad Horizontal

Resumen

La escalabilidad horizontal —también llamada scale out— es la capacidad de un sistema de manejar más carga agregando más instancias o nodos en lugar de aumentar los recursos (CPU, RAM, disco) de una máquina existente. Si un servidor puede atender 1000 requests por segundo, con escalabilidad horizontal ponés dos servidores y atendés 2000, cuatro y atendés 4000.

Importa porque es el modelo que permite construir sistemas que crecen con la demanda sin un límite físico. Una máquina tiene un techo: el procesador más rápido del mercado, la máxima RAM que soporta la placa. Pero con escalabilidad horizontal, el límite teórico es cuántas máquinas podés agregar, y eso escala mucho más lejos.

La escalabilidad horizontal no es gratis. Exige que la aplicación esté diseñada para ejecutarse en múltiples instancias sin compartir estado local —statelessness—, que el tráfico se distribuya correctamente entre instancias —load balancing—, y que los datos compartidos —bases de datos, cachés, colas— también puedan escalar. Es una decisión de arquitectura, no una configuración que se activa con un flag.

Alcance y supuestos

Este paquete cubre la escalabilidad horizontal como concepto: qué es, cómo se diferencia de la vertical, qué exigencias impone al diseño de software y qué trade-offs introduce en consistencia, coordinación y costo operativo. También introduce la relación con arquitecturas stateless y shared-nothing.

No cubre mecanismos específicos de auto-scaling (Kubernetes HPA, AWS Auto Scaling Groups), estrategias de sharding de bases de datos más allá de una mención conceptual, ni capacity planning y load testing.

Asume que entendés qué es un servidor o una instancia de aplicación a nivel general.

Modelo mental

Imaginá una autopista con un solo carril. Si hay 100 autos por hora, fluye bien. Si hay 1000, se congestiona. Podés ensanchar el carril para que entren más autos —escalabilidad vertical—, pero eventualmente el ancho máximo está limitado por el terreno. La otra opción es agregar más carriles —escalabilidad horizontal—: con dos carriles pasan 2000 autos, con cuatro pasan 4000.

El desafío está en el peaje. Con un solo carril, una casilla de peaje alcanza. Con cuatro carriles, necesitás cuatro casillas y alguien que distribuya los autos entre ellas para que no se amontonen todas en el primer carril. Ese alguien es el balanceador de carga. Y si todas las casillas comparten una base de datos de patentes buscadas, esa base de datos también tiene que escalar, o se convierte en el nuevo cuello de botella.

Uso práctico

La escalabilidad horizontal es la estrategia correcta cuando:

• ✅ La carga es variable e impredecible, y necesitás agregar o quitar capacidad bajo demanda.
• ✅ El sistema puede diseñarse sin estado local —cada request es independiente y no depende de qué instancia lo atiende—.
• ✅ El costo de muchas máquinas pequeñas es menor que el de una máquina grande.
• ❌ La aplicación guarda estado en memoria local (sesiones, cachés locales) y migrarla a stateless es más caro que escalar verticalmente.
• ❌ La base de datos es monolítica y ya es el cuello de botella: agregar instancias de aplicación no va a ayudar.

Statelessness: la condición necesaria

La escalabilidad horizontal requiere que cualquier instancia pueda atender cualquier request. Si una instancia guarda la sesión del usuario en memoria, el balanceador de carga tiene que asegurarse de que ese usuario siempre llegue a la misma instancia —sticky sessions—, lo cual anula gran parte del beneficio de escalar horizontalmente.

La alternativa es externalizar el estado:

// Mal: estado local que impide escalar horizontalmente
const sessions = new Map<string, UserSession>();

function handleRequest(userId: string) {
  const session = sessions.get(userId); // solo existe en ESTA instancia
}

// Bien: estado externalizado, cualquier instancia puede atender
function handleRequest(userId: string) {
  const session = await redis.get(`session:${userId}`); // compartido entre instancias
}

Redis, Memcached, o la propia base de datos son almacenes compartidos que todas las instancias consultan. Eso permite que el balanceador de carga envíe requests a cualquier instancia indistintamente.

Contraste con escalabilidad vertical

| Aspecto | Horizontal (scale out) | Vertical (scale up) | |---|---|---| | Método | Agregar más instancias | Agregar más CPU/RAM a una instancia | | Límite | Teóricamente ilimitado | Físico (hardware máximo disponible) | | Complejidad de software | Alta (stateless, load balancing, datos compartidos) | Baja (la app no necesita cambios) | | Costo | Muchas máquinas baratas | Una máquina cara | | Disponibilidad | Alta (si una instancia falla, otras siguen) | Baja (si la máquina falla, todo cae) | | Ejemplo | Kubernetes con 50 pods | Una EC2 que pasa de t3.micro a t3.2xlarge |

En la práctica, la mayoría de los sistemas usan una combinación: escalan horizontalmente la capa de aplicación (stateless) y verticalmente la base de datos (hasta que es necesario shardear, que es escalabilidad horizontal aplicada a datos).

Ejemplo trabajado: escalar una API de tareas

Una API de tareas creció de 100 a 10 000 requests por minuto. El equipo evalúa dos caminos.

Camino A — vertical: cambiar la instancia de 2 vCPU / 4 GB RAM a 8 vCPU / 32 GB RAM. La app no cambia. Costo: $200/mes extra. Límite: cuando la instancia más grande disponible no alcance, no hay a dónde ir.

Camino B — horizontal: poner 4 instancias de 2 vCPU / 4 GB RAM detrás de un balanceador de carga. Requisitos:

1. Externalizar sesiones a Redis.
2. Mover archivos subidos a S3 en vez del disco local.
3. Configurar el balanceador para distribuir tráfico round-robin.

Costo: 4 × $40 + Redis $30 = $190/mes. Beneficio adicional: si una instancia falla, las otras tres siguen atendiendo. Cuando el tráfico baje a la noche, se pueden apagar dos instancias y ahorrar.

El equipo elige el camino B. Las primeras dos semanas duele migrar las sesiones y los archivos. Después, escalar es agregar o quitar instancias según la demanda. A los seis meses, con 100 000 requests por minuto, simplemente pasan de 4 a 10 instancias sin tocar el código. La inversión inicial en statelessness se pagó con creces.

Evidencia

• La distinción entre scale up y scale out es un concepto transversal en la ingeniería de sistemas distribuidos. La arquitectura stateless y shared-nothing, documentada en la literatura de sistemas distribuidos y en las prácticas de plataformas como Kubernetes y AWS, es la precondición para la escalabilidad horizontal efectiva.