Escalar un servidor no es «comprar uno más grande». Es responder a una pregunta concreta: ¿el problema está en la potencia, en la arquitectura o en el código? Pasar a una máquina el doble de potente sin diagnosticar suele resolver el síntoma a corto plazo y volver al mismo problema en pocos meses.
Esta guía explica las señales reales de que tu servidor necesita escalar, las dos formas básicas de hacerlo y cómo decidir sin sobre-dimensionar.
Tabla de contenidos
Qué significa escalar de verdad
Escalar es aumentar la capacidad para aceptar más carga. Hay dos modelos básicos:
- Vertical (más recursos al mismo servidor): subir CPU, RAM o disco. Sencillo, rápido, con un techo físico claro y un único punto de fallo.
- Horizontal (más servidores trabajando en paralelo): repartir carga entre varias instancias detrás de un balanceador. Sin techo práctico pero requiere arquitectura adecuada (estado externalizado, base de datos compartida, sesiones).
No siempre el horizontal es «mejor»: un escalado vertical bien ajustado puede ser más barato y simple para cargas estables. El horizontal es necesario cuando hay que aguantar fallos, cuando la carga es variable o cuando ya has llegado al límite de la máquina más grande disponible.
Señales claras de que toca escalar
CPU o memoria al 80-100% sostenido
Picos puntuales son normales. Sostener el 80% durante 30 minutos en horario laboral significa que vas justo y que cualquier evento extra te tira.
Latencia alta
Time To First Byte por encima de 1 segundo de forma habitual, o p95 de respuesta > 2 segundos. La caída de conversión empieza mucho antes de la caída completa.
Errores 5xx en logs
Errores 502, 503, 504 indican backend saturado o tiempo de respuesta agotado. Si aparecen con regularidad, el servidor está sirviendo más allá de su capacidad.
Base de datos al límite
Queries lentas, locks crecientes, conexiones agotadas (max_connections). La base de datos suele tocar techo antes que el resto, sobre todo en aplicaciones leídas-pesadas.
Caídas con tráfico predecible
Si caes cada vez que lanzas una campaña, promoción o boletín, no hay margen para crecer sin redimensionar.
Cómo decidir entre vertical y horizontal
| Situación | Opción más razonable |
|---|---|
| Carga estable, crecimiento lineal previsible | Vertical (más sencillo, suficiente) |
| Picos puntuales (campañas, eventos) | Horizontal con auto-scaling |
| Alta disponibilidad obligatoria | Horizontal (mínimo 2 instancias) |
| Ya estás en la instancia más grande | Horizontal o cambiar de arquitectura |
| Equipo pequeño sin DevOps | Vertical, salvo necesidad real |
Antes de tomar la decisión:
- Mide. Sin métricas (CPU, memoria, latencia, errores) estás adivinando.
- Perfila el código. Una optimización de la query lenta del ranking puede ahorrarte triplicar la máquina.
- Si vas a horizontal, prepara el código primero: sin sesiones en memoria local, sin estado en disco local, sin asunciones de «una sola máquina».
Errores comunes al escalar
- Tirar más CPU sin perfilar: caro y suele no resolver el problema real.
- Pasar a horizontal sin desacoplar estado: sesiones que se pierden, archivos que no aparecen, caché incoherente.
- No revisar la base de datos: escalar el frontend cuando el cuello de botella está en la BD no aporta.
- Sobre-dimensionar «por si acaso»: gastas el doble por una capacidad que solo usas el 5% del tiempo. Auto-scaling resuelve este problema.
Preguntas frecuentes
¿Cuándo sé que necesito escalar el servidor y no solo optimizar?
Cuando, ya con el código y la base de datos perfilados, la CPU o la memoria se mantienen al 80-100% en horario laboral, la latencia (TTFB > 1 s o p95 > 2 s) es habitual o aparecen errores 5xx con regularidad. Si el cuello de botella es una query lenta o una caché mal configurada, primero se optimiza: escalar sin diagnosticar suele tapar el síntoma unos meses.
¿Qué diferencia hay entre escalado vertical y horizontal?
El vertical añade CPU, RAM o disco al mismo servidor: es sencillo y rápido, pero tiene un techo físico y un único punto de fallo. El horizontal reparte la carga entre varias instancias detrás de un balanceador: no tiene techo práctico y aporta tolerancia a fallos, pero exige preparar la arquitectura (estado y sesiones externalizados).
¿Siempre es mejor escalar en horizontal?
No. Para cargas estables y crecimiento previsible, un vertical bien ajustado es más barato y simple. El horizontal es necesario cuando hay que tolerar fallos, cuando la carga es muy variable (picos de campañas) o cuando ya estás en la instancia más grande disponible.
¿Cómo evito pagar de más al escalar?
Mide antes de decidir y no sobre-dimensiones «por si acaso». Para picos puntuales, el auto-scaling te da capacidad solo cuando hace falta en lugar de pagar el doble todo el mes. Y revisa siempre la base de datos: muchas veces el cuello de botella está ahí y escalar el frontend no aporta nada.
¿Necesitas evaluar tu infraestructura?
En Elimática dimensionamos y escalamos infraestructuras para entornos productivos: detectamos el cuello de botella real antes de proponer cambios y proponemos solo lo que mueve la métrica.