Escalabilidad Vertical

Resumen

La escalabilidad vertical —scale up— es la estrategia de mejorar la capacidad de un sistema aumentando los recursos de hardware de una máquina existente: más núcleos de CPU, más memoria RAM, almacenamiento más rápido. Donde la escalabilidad horizontal agrega más instancias, la vertical hace la instancia más grande.

Importa porque es la forma más simple de escalar: no requiere cambios en la arquitectura del software. Si una aplicación funciona en un servidor con 4 GB de RAM, pasar a 16 GB duplica o triplica su capacidad sin tocar una línea de código. Para muchos sistemas —especialmente bases de datos y aplicaciones monolíticas que no se diseñaron para ser distribuidas—, la escalabilidad vertical es la primera opción y a veces la única viable.

El límite es físico: existe un procesador más rápido del mercado, una cantidad máxima de RAM que soporta una placa madre, una velocidad de disco que no se puede superar. Además, una sola máquina es un punto único de falla: si esa máquina se cae, todo el sistema deja de funcionar.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

Una camioneta de carga versus una flota de motos. Si necesitás mover más paquetes, podés cambiar la camioneta por un camión más grande. Eso es escalabilidad vertical. Eventualmente ningún camión entra por la calle, o el costo del camión es prohibitivo, y ahí necesitás una flota de vehículos más chicos —escalabilidad horizontal—.

En software, la camioneta es tu servidor. Cambiar de una instancia con 2 vCPU a una con 8 vCPU es como cambiar de una camioneta a un camión. Es inmediato y efectivo, pero tiene un techo.

Uso práctico

La escalabilidad vertical es la opción correcta cuando:

• ✅ La aplicación no está diseñada para ejecutarse en múltiples instancias —guarda estado en memoria o en disco local—.
• ✅ La carga crece de manera predecible y gradual, sin picos que requieran agregar y quitar instancias dinámicamente.
• ✅ El costo y la complejidad de externalizar el estado superan el beneficio de escalar horizontalmente.
• ❌ La aplicación necesita alta disponibilidad: una sola máquina es un punto único de falla.
• ❌ El crecimiento es impredecible y necesitás escalar bajo demanda sin límite físico.

Contraste práctico

| Aspecto | Vertical | Horizontal | |---|---|---| | Complejidad de código | Mínima | Alta (stateless, balanceo, datos compartidos) | | Límite | Hardware máximo | Teóricamente ilimitado | | Disponibilidad | Baja (SPOF) | Alta | | Costo inicial | Bajo | Medio-alto | | Costo marginal | Alto (máquinas más grandes) | Bajo (máquinas baratas) | | Caso típico | Base de datos, monolitos legacy | APIs, microservicios, web servers |

La mayoría de los sistemas modernos escalan la capa de aplicación horizontalmente y la base de datos verticalmente —hasta que el crecimiento obliga a shardear—. Lo importante es saber que existen las dos estrategias y que no son mutuamente excluyentes.

Ejemplo trabajado: escalar verticalmente una base de datos

Una aplicación SaaS crece de 100 a 5000 usuarios. La base de datos PostgreSQL empieza a mostrar latencia alta en queries de reportes. El equipo escala verticalmente: pasa de una instancia de 4 vCPU / 16 GB RAM a una de 16 vCPU / 64 GB RAM. La latencia baja sin tocar una línea de código. A los 6 meses, con 20 000 usuarios, la instancia más grande disponible ya no alcanza y el equipo migra a sharding —escalabilidad horizontal—. La vertical compró tiempo para planificar la migración sin urgencia.

Evidencia

• Wikipedia, Scalability distingue los dos enfoques de escalabilidad —horizontal y vertical— y describe las ventajas y límites de cada uno en el contexto de sistemas distribuidos.