Qué significa que un software sea escalable

Casi todas las conversaciones sobre desarrollo de software incluyen, en algún momento, la palabra "escalable". Es uno de esos términos que se usan tanto que pierden significado: todo el mundo dice que su software es escalable, que su arquitectura es escalable, que la solución que proponen escala. Pero cuando un fundador o un gerente pregunta "¿esto es escalable?", rara vez recibe una respuesta que pueda evaluar sin conocimientos técnicos.

Este artículo intenta cerrar esa brecha. Explica qué significa que un software sea escalable, cómo distinguirlo de otros conceptos con los que suele confundirse —en particular, la velocidad o performance— y qué implicancias tiene para un negocio que su tecnología no esté preparada para crecer.

Escalabilidad no es velocidad

La confusión más frecuente es tratar escalabilidad y performance como si fueran lo mismo. No lo son, y entender la diferencia es el primer paso para tener conversaciones técnicas más productivas.

Performance responde a la pregunta: ¿qué tan rápido responde el sistema con la carga que tiene hoy? Si tu aplicación tarda dos segundos en mostrar un listado de clientes cuando hay cien clientes cargados, eso es un problema de performance.

Escalabilidad responde a otra pregunta: ¿qué pasa con ese tiempo de respuesta cuando los clientes pasan de cien a diez mil, o de diez mil a un millón? Si el sistema tarda dos segundos con cien clientes y sigue tardando dos segundos con cien mil, es escalable —mantiene su performance cuando la carga crece—. Si tarda dos segundos con cien clientes y veinte segundos con mil, no escala —su performance se degrada a medida que la demanda aumenta—.

Un ejemplo concreto: un restaurante con una cocina bien organizada puede servir veinte platos en treinta minutos. Si llegan cuarenta comensales de golpe, la cocina puede tardar sesenta minutos —se degrada, no escala— o puede mantener los treinta minutos si tiene más cocineros, más hornallas y un proceso que lo permite —escala—. La velocidad de cada plato individual —la performance— puede ser la misma en ambos casos. Lo que cambia es la capacidad del sistema completo para absorber más trabajo sin degradarse.

Los dos tipos de escalabilidad que importan

Cuando se habla de escalabilidad en software, suelen mencionarse dos enfoques: escalabilidad vertical y escalabilidad horizontal. Los nombres suenan técnicos, pero los conceptos son simples.

Escalabilidad vertical: una máquina más grande

Es el equivalente a cambiar el motor de un auto por uno más potente. Si tu aplicación corre en un servidor y ese servidor se queda sin recursos —memoria, procesador, disco—, le ponés un servidor más grande. Más RAM, más CPU, más almacenamiento.

La escalabilidad vertical es simple de implementar y suele ser suficiente para muchas aplicaciones durante bastante tiempo. Pero tiene un límite: en algún momento, el servidor más grande que existe en el mercado no alcanza, o el costo de ese servidor se vuelve desproporcionado.

Escalabilidad horizontal: más máquinas

Es el equivalente a sumar más cocineros en lugar de pedirle al único cocinero que cocine más rápido. En vez de reemplazar el servidor por uno más grande, se agregan más servidores que trabajan en paralelo, repartiéndose la carga.

La escalabilidad horizontal es más compleja de implementar porque requiere que el software esté diseñado desde el inicio para funcionar sobre múltiples máquinas: cómo se reparte el trabajo, cómo se asegura que dos servidores no procesen lo mismo dos veces, cómo se mantienen los datos consistentes entre todas las máquinas. Pero no tiene el límite físico de la escalabilidad vertical: en teoría, podés seguir agregando servidores indefinidamente.

Cómo se manifiesta un problema de escalabilidad en la práctica

Los problemas de escalabilidad no se anuncian. Aparecen como síntomas que, vistos por separado, parecen tener otras causas:

• La aplicación se pone lenta en ciertos horarios. Si todos los usuarios se conectan a la misma hora —por ejemplo, un sistema de gestión que todo el equipo usa al arrancar la mañana— y el sistema se arrastra durante esa franja, es una señal de que el sistema no escala bien con usuarios concurrentes.
• Algunas funcionalidades dejan de responder. No falla todo el sistema: solo una parte. Por ejemplo, el listado de productos tarda diez segundos, pero el resto de la aplicación funciona normal. Esto suele indicar que una consulta a la base de datos no está preparada para el volumen de datos actual.
• Los backups empiezan a interferir con la operación. Cuando la base de datos crece, hacer una copia de seguridad puede consumir tantos recursos que el sistema se vuelve inusable durante el proceso. Lo que antes tomaba cinco minutos de madrugada ahora toma dos horas y se solapa con el horario laboral.
• Facturas o reportes que antes salían en segundos ahora tardan minutos. La lógica no cambió, pero el volumen de datos sobre el que se ejecuta creció. El algoritmo que procesa mil transacciones en un segundo no necesariamente procesa un millón en el mismo tiempo.

Estos síntomas comparten una característica: empeoran de forma gradual. Un día la aplicación tarda un poco más; al mes siguiente, bastante más; a los seis meses, hay funcionalidades directamente inusables. Como el deterioro es progresivo, el equipo se adapta —"esperamos un poco más, no es para tanto"— hasta que el problema ya afecta la operación del negocio.

Relacionado: si estás detectando estos síntomas, probablemente también sea momento de revisar qué preparar antes de escalar tu producto, porque la escalabilidad técnica es solo una parte de la ecuación: el equipo, los procesos y el modelo de negocio también tienen que estar listos para crecer.

¿Mi software necesita ser escalable?

La respuesta honesta es: depende. No todo software necesita escalar a millones de usuarios. Un sistema interno que usan quince empleados probablemente nunca enfrente un problema de escalabilidad. Un catálogo de productos para un ecommerce chico puede funcionar perfectamente con una arquitectura simple durante años.

Pero hay situaciones donde la escalabilidad debería estar en la conversación desde el inicio:

• El volumen de datos crece con el uso. Si cada usuario, cada transacción o cada día de operación agrega datos que el sistema tiene que procesar, el volumen acumulado tarde o temprano va a poner a prueba la arquitectura.
• El negocio depende de que el sistema esté disponible en momentos de pico. Un sistema de venta de entradas para eventos, una plataforma de e-learning en época de exámenes, una aplicación de delivery en hora pico: si el sistema se cae justo cuando más se necesita, el costo no es técnico, es comercial.
• El plan de crecimiento del negocio proyecta multiplicar la base de usuarios. Si hoy tenés cien usuarios y tu plan de negocio proyecta diez mil en dos años, la arquitectura actual probablemente no aguante sin cambios.

Para proyectos que recién empiezan, la conversación sobre escalabilidad puede esperar. El artículo sobre cómo definir el alcance de un MVP propone un enfoque útil: construir lo mínimo que permita validar la idea, sin sobreinvertir en infraestructura para una escala que todavía no existe. La escalabilidad se diseña cuando el producto está validado y el crecimiento es una certeza, no una esperanza.

Qué puede hacer un proveedor para que un software escale

Si estás evaluando un proveedor de desarrollo —sea una agencia, un freelancer o tu propio equipo técnico—, estas son algunas prácticas que distinguen un enfoque que considera la escalabilidad de uno que no:

• Diseñan pensando en el mediano plazo, no solo en la entrega de mañana. No hace falta construir para un millón de usuarios desde el día uno, pero sí evitar decisiones que hagan imposible o extremadamente costoso crecer después. Por ejemplo: elegir una base de datos que no soporta el volumen de datos proyectado a dos años.
• Separan lo que cambia de lo que no. El código que maneja las reglas de negocio —qué descuento aplica a qué cliente— debería estar separado del código que maneja cómo se guardan los datos o cómo se muestra la información. Si todo está mezclado, cualquier cambio chico puede romper cualquier parte del sistema.
• Miden antes de optimizar. Un buen equipo técnico no adivina dónde está el cuello de botella: mide. Antes de gastar tiempo en hacer algo más rápido, identifica qué es lo que efectivamente está frenando al sistema.
• Hacen pruebas de carga, al menos en los puntos críticos. Simular cien, mil o diez mil usuarios concurrentes sobre las funcionalidades más exigentes —aunque sea una vez antes de un lanzamiento importante— detecta problemas de escalabilidad antes de que los detecten los usuarios reales.

Lo que la escalabilidad no resuelve

Así como es importante entender qué es la escalabilidad, también conviene tener claro qué no es:

• No es un seguro contra todos los problemas técnicos. Un sistema puede ser perfectamente escalable y aun así tener bugs, fallas de seguridad o una mala experiencia de usuario.
• No reemplaza un buen proceso de desarrollo. Si el equipo que construye no tiene prácticas de testing, revisión de código o control de versiones, la arquitectura más escalable del mundo no va a salvar el proyecto.
• No es binario. Un sistema no es "escalable" o "no escalable". Es más o menos escalable en distintas dimensiones: puede escalar bien en cantidad de usuarios pero mal en volumen de datos, o viceversa.

La escalabilidad es una propiedad del sistema que se diseña, se verifica y se ajusta a lo largo del tiempo. No es una casilla que se marca en una propuesta comercial. Y, sobre todo, es una inversión que se justifica cuando el crecimiento del negocio la necesita. Gastar en escalabilidad para un producto que todavía no encontró su mercado es como ampliar la cocina de un restaurante que todavía no tiene clientes: la inversión es real, pero el momento quizás no.