Definición
La escalabilidad es la capacidad de un sistema para atender más carga —más usuarios, más datos, más peticiones— sin que el servicio se degrade.
Y conviene empezar por lo que no es: escalabilidad no es velocidad. Un sistema puede ser rapidísimo con diez usuarios y hundirse con mil; otro puede ser mediocre con diez y comportarse igual con diez mil. Son propiedades distintas.
Vertical y horizontal
Vertical. Poner una máquina más grande: más procesador, más memoria, disco más rápido.
Es lo más sencillo —no exige cambiar nada— y tiene dos límites: hay un techo físico y el precio crece más rápido que la potencia. Además, sigue habiendo una sola máquina, así que sigue habiendo un único punto de fallo.
Horizontal. Poner más máquinas y repartir el trabajo entre ellas con un balanceador de carga.
No tiene techo práctico y da tolerancia a fallos, y a cambio exige que la aplicación esté preparada. Ahí está el trabajo real.
Qué hay que cambiar para escalar en horizontal
Tres cosas, y son siempre las mismas:
Nada de estado local. Si la sesión del usuario vive en la memoria de un servidor, la segunda petición puede caer en otro y el usuario aparece desconectado. La sesión debe ir a un almacén compartido.
Nada de ficheros en disco local. Si un usuario sube un documento a la máquina A, la máquina B no lo tiene. Los ficheros van a un almacenamiento compartido.
Tareas programadas que no se dupliquen. Si el mismo trabajo periódico corre en las tres máquinas, se ejecuta tres veces. Ver tarea programada.
Ejemplo práctico
Cuando un sistema empieza a ir lento, la reacción habitual es contratar más servidor. A veces funciona. Muy a menudo es dinero tirado.
Lo que aprendí: en sistemas de gestión, el cuello de botella casi nunca es la potencia de la máquina. Los tres sitios donde suele estar, por orden de frecuencia:
Consultas mal planteadas. Una consulta N+1 o una tabla sin índice hunden un listado por muchos núcleos que tenga el servidor.
Ausencia de caché en cálculos que se repiten idénticos cientos de veces.
Operaciones lentas hechas en línea que deberían ir a una cola.
Los tres se arreglan con cambios de código y ninguno mejora comprando máquina. De ahí la frase que resume el asunto: más servidor no arregla un mal algoritmo.
El segundo aprendizaje, sobre el orden correcto: primero medir, después optimizar, y solo entonces escalar. Sin medición no sabes qué está lento, y optimizas por intuición — que en rendimiento acierta muy poco. Ver observabilidad.
Y una advertencia sobre escalar demasiado pronto: diseñar para millones de usuarios cuando tienes cincuenta multiplica la complejidad, el coste y el número de piezas que pueden fallar. Un sistema simple bien construido aguanta muchísimo más de lo que la gente supone, y se puede escalar cuando haga falta. La mayoría de negocios nunca llegan al punto en que la arquitectura sea el límite.
Errores comunes
- Comprar servidor sin medir dónde está el problema.
- Escalar en horizontal con estado guardado en local.
- Ficheros en disco local en una arquitectura de varias máquinas.
- Duplicar tareas programadas.
- Escalar la aplicación y dejar la base de datos como único cuello.
- Diseñar para una escala que no existe.
- Confundir lento con no escalable.
Cuándo plantearlo
Cuando el rendimiento se degrade al crecer la carga, no cuando simplemente sea mejorable.
La pregunta que ordena la decisión: ¿el sistema va lento siempre, o solo cuando hay mucha gente? Si va lento siempre, es un problema de código. Si solo con carga, entonces sí es escalabilidad — y aun así conviene medir antes de comprar.
