Antes de escalar un servidor hay que saber si 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.
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).
El horizontal no siempre 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.
¿Necesitas evaluar tu infraestructura?
En Elimática dimensionamos y escalamos infraestructuras en producción. Primero buscamos el cuello de botella real y después proponemos solo los cambios que mejoran la métrica.