No he tratado mucho con este término directamente, y supongo que sería fácil encontrar una definición de libro de texto en Google. Pero he tenido problemas relacionados con la escalabilidad en mi trabajo de desarrollo, por lo que voy a proporcionar mi comprensión del término desde mi experiencia como programador sin haber buscado nada.
La escalabilidad es una consideración importante para un ingeniero de software que está diseñando o implementando un sistema que es probable que tome una carga mucho más pesada que la que se experimentará en un entorno de prueba. Pero espero que en realidad se refiera no sólo a la capacidad de asumir una carga pesada, sino a reflejar las capacidades basadas en los recursos que se le dan.
Por ejemplo, considere un sistema que puede permitir que los resultados de búsqueda devuelvan una lista completa de artículos en 3 segundos. Una solución no escalable podría requerir una dirección de servidor dedicada exclusivamente a indexar las palabras clave de los artículos. Esta solución no se adapta a una situación en la que sólo se tienen unos cientos de artículos de unos pocos miles de palabras cada uno. Esto podría mantenerse fácilmente en un solo servidor, y tener que crear un servidor separado para la indexación sería excesivo y un derroche. Otra solución no escalable podría buscar secuencialmente los artículos con una simple búsqueda de texto cada vez que se hace una petición, y no tiene una forma de dividir la carga de trabajo. Esta solución falla en la escalabilidad de múltiples maneras: no proporciona ningún medio para aprovechar los recursos adicionales (dividir la carga de trabajo) y lo hace mal al no optimizar la forma en que se realiza el trabajo cuando se trata de una gran cantidad de datos.
Si usted tiene mil millones de artículos que no están indexados de alguna manera, buscar a través de ellos secuencialmente en 3 segundos va a requerir muchos más recursos que un sistema que mantiene los datos en una forma optimizada para la búsqueda repetida de grandes cantidades de datos. Una solución escalable a este problema utilizará los recursos de forma óptima tanto para pequeñas como para grandes cantidades de datos, y puede hacer un buen uso de cualquier recurso que se le dé en lugar de asumir una tarea grande o una tarea pequeña.
Un ejemplo de un problema de escalabilidad con el que he estado personalmente involucrado es cuando diseñé un sistema para procesar datos para un sistema ERP en memoria para optimizar el rendimiento. Había algunos sistemas en los que había cientos de miles de registros y cargarlos en memoria tenía un rendimiento pobre en el mejor de los casos, y directamente fallaba en el peor. La arquitectura de memoria de los sistemas implicados no estaba diseñada para utilizar la memoria a estas escalas de esta manera. Un sistema más escalable habría confiado más en el almacenamiento persistente y la indexación y no habría asumido que se podía cargar tanto en la memoria de trabajo.
Otro ejemplo es la reconstrucción de las estructuras de información de seguridad de las grandes empresas. Tenemos un procedimiento para borrar y reconstruir esta información basado en datos jerárquicos que definen quién tiene acceso a qué partes de la empresa. Lo hemos probado en sistemas con unos cuantos miles de empleados en unos cientos de sucursales. Pero cuando se ejecuta en un sistema en el que hay cientos de miles de empleados en miles de sucursales, el proceso de reconstrucción resultaba requerir más tiempo del práctico, y no había’ manera de asignar más recursos a la tarea para completarla más rápidamente.
Para mejorar la escalabilidad de nuestra segunda solución, estamos implementando la capacidad de dividir el trabajo entre más procesadores, e investigando soluciones optimizadas, que requieren procedimientos de prueba que operen con más datos.
Por lo general, los problemas de escalabilidad se encuentran en los fallos de escalado para manejar cargas de trabajo más grandes. No he participado en soluciones que hayan fallado a la hora de escalar hacia abajo.