Una explicación sin tecnicismos de por qué cambiar la escala cambia todo: la analogía del restaurante y los problemas que aparecen cuando un sistema crece en usuarios.
Hay una pregunta que todo fundador o empresario se hace en algún momento, generalmente después de ver que el producto que construyó funciona bien con los primeros usuarios: "si ya funciona con diez, ¿por qué no va a funcionar con cien, o con mil? Es cuestión de agregar más potencia, ¿no?".
La respuesta corta es que no, no es cuestión de agregar más potencia. La respuesta larga es lo que explica este artículo, usando una analogía que no requiere saber nada de programación para entender por qué la escala lo cambia todo.
Imaginá un restaurante chico, de barrio, con diez mesas. El dueño cocina, atiende las mesas, cobra y limpia. Conoce a la mayoría de los clientes por el nombre. Cuando llega un pedido, va a la cocina, lo prepara, lo sirve, y vuelve a la caja. El sistema funciona: los platos salen calientes, los clientes están contentos, el negocio es rentable.
Ahora imaginá que ese mismo restaurante, sin cambiar absolutamente nada —misma cocina, mismo dueño haciendo todo, mismos procesos— recibe de golpe a cien comensales. Todos piden al mismo tiempo. El dueño intenta tomar los pedidos, pero mientras anota el pedido de la mesa tres, la mesa siete ya está reclamando. Entra a la cocina y no sabe por dónde empezar. Los platos salen fríos, incompletos o directamente no salen. Algunos clientes se van sin que nadie los haya atendido. El restaurante colapsa.
¿Cambió algo en la calidad de la comida o en la capacidad del dueño? No. Lo que cambió fue la escala, y la escala expuso que los procesos, las herramientas y la estructura que funcionaban para diez mesas no funcionan para cien.
Con el software pasa exactamente lo mismo. Las técnicas, arquitecturas y decisiones que son perfectamente válidas para una aplicación con pocos usuarios se vuelven insuficientes —y a veces contraproducentes— cuando los usuarios se multiplican.
Para entender por qué escalar no es "lo mismo pero más grande", conviene separar el problema en tres dimensiones diferentes. Cada una de ellas se comporta de manera distinta cuando crece el número de usuarios.
Con diez usuarios, la probabilidad de que dos personas quieran hacer exactamente lo mismo al mismo tiempo es baja. El sistema puede procesar cada solicitud de a una, en orden, sin que nadie note la diferencia.
Con mil usuarios, en cualquier momento dado va a haber decenas de personas queriendo hacer cosas distintas —o peor, queriendo hacer lo mismo— de forma simultánea. Si el sistema procesa de a una, se forma una fila de espera que crece más rápido de lo que el sistema puede procesar. Algunos usuarios reciben respuesta; otros ven la pantalla en blanco hasta que se cansan y cierran.
Resolver la concurrencia requiere diseñar el sistema para que pueda manejar múltiples solicitudes en paralelo sin que se pisen entre sí. Y hacer eso bien es uno de los desafíos más difíciles de la ingeniería de software: dos usuarios que compran el último producto disponible en stock, dos personas que editan el mismo documento, dos transacciones que modifican el mismo registro contable. Si el sistema no está preparado para manejar esos conflictos, los datos se corrompen y el negocio pierde plata o credibilidad.
Volviendo al restaurante: con diez mesas, el dueño puede preparar un plato por vez porque rara vez dos mesas piden al mismo tiempo. Con cien mesas, si prepara un plato por vez, la última mesa come dos horas después de haber llegado. Necesita varios cocineros trabajando en paralelo, y un sistema para que no se mezclen los pedidos. En software, eso implica cambiar la arquitectura del sistema.
Con diez usuarios, la base de datos tiene unos pocos cientos de registros. Cualquier búsqueda es instantánea porque el sistema puede recorrer todos los datos en milisegundos.
Con mil usuarios —y el tiempo de uso acumulado—, la base de datos puede tener millones de registros. Recorrerlos todos para cada búsqueda ya no funciona: tardaría segundos o minutos. El sistema necesita índices, estrategias de paginación, y en muchos casos arquitecturas de datos completamente distintas.
Pero el problema no es solo la velocidad de las consultas. También está la integridad de los datos: con diez usuarios, que un registro quede duplicado o inconsistente es un problema menor que se corrige a mano. Con mil usuarios, ese mismo problema puede generar cientos de registros incorrectos antes de que alguien lo detecte, y corregirlos a mano es inviable.
La infraestructura que sirve para diez usuarios —un servidor modesto, una base de datos en la misma máquina, backups manuales cada tanto— es económicamente eficiente y operativamente simple.
Para mil usuarios, esa misma infraestructura se cae. El servidor se queda sin memoria, la base de datos compite por recursos con la aplicación, y el backup manual que antes tomaba cinco minutos ahora tarda horas y afecta el rendimiento del sistema mientras se ejecuta.
Escalar la infraestructura no es solamente comprar un servidor más grande: es decidir cómo distribuir la carga entre varios servidores, cómo asegurarse de que si uno falla los otros sigan funcionando, y cómo hacer todo eso sin que el costo mensual de infraestructura se coma el margen del negocio.
La intuición más común frente a un problema de escalabilidad es tirar más hardware: más memoria, más procesador, un servidor más grande. A eso se le llama escalado vertical, y en muchos casos funciona. Pero tiene un límite físico y uno económico.
El límite físico es que, eventualmente, el servidor más potente que existe en el mercado no alcanza para la carga que tenés. El límite económico es que duplicar la potencia de un servidor no duplica su capacidad de procesar solicitudes —la relación no es lineal—, pero sí aumenta el costo de manera significativa.
La alternativa es el escalado horizontal: en lugar de un servidor enorme, muchos servidores chicos trabajando en paralelo. Pero esa estrategia requiere que el software esté diseñado para funcionar en múltiples servidores desde el principio. Si la aplicación fue construida asumiendo que corre en una sola máquina, migrar a una arquitectura distribuida puede ser más complejo y costoso que rehacer partes enteras del sistema.
Muchos proyectos caen en la trampa de ir comprando servidores cada vez más grandes a medida que crecen, en lugar de rediseñar la arquitectura para escalar horizontalmente. Funciona durante un tiempo, hasta que llegan a un punto en que el servidor más potente del mercado se queda corto —y para entonces la deuda de no haber rediseñado antes es enorme.
Cuando un producto está en su etapa inicial con pocos usuarios, las prioridades de desarrollo son claras: construir funcionalidades rápido, validar hipótesis, llegar al mercado antes que los competidores. La calidad del código, la escalabilidad y la automatización de pruebas son preocupaciones secundarias —y es razonable que así sea, porque si el producto no funciona en el mercado, nada de eso importa.
Pero cuando el producto empieza a crecer, esas prioridades tienen que cambiar. Las funcionalidades nuevas pierden urgencia relativa frente a la estabilidad del sistema. Una funcionalidad nueva que le sirve al diez por ciento de los usuarios no compensa el riesgo de que el sistema se caiga para el cien por ciento.
Este cambio de prioridades es difícil de gestionar porque va contra la inercia del equipo. Si durante dos años la métrica de éxito fue "cuántas funcionalidades nuevas sacamos este mes", pedirle al equipo que dedique un mes entero a hacer que las funcionalidades existentes soporten más usuarios requiere un cambio de cultura y de expectativas.
El artículo sobre qué significa que un software sea escalable profundiza en qué implica técnicamente la escalabilidad y qué preguntas hacerle a tu equipo para saber si están construyendo con la escala en mente desde el principio.
Si ya estás operando con algunos usuarios y te preocupa lo que pueda pasar cuando crezcas, estas son las señales más evidentes de que tu solución actual no está preparada para escalar:
No todas las aplicaciones necesitan estar preparadas para mil usuarios desde el día uno. Esa inversión no siempre se justifica, sobre todo si el producto está en etapa de validación. Pero hay un punto en el que posponer las decisiones de escalabilidad deja de ser una estrategia razonable y se convierte en un riesgo existencial para el negocio.
Ese punto suele llegar cuando:
La decisión no es trivial porque rediseñar para escalar cuesta tiempo y dinero que no se invierten en funcionalidades nuevas visibles para el cliente. Pero el costo de no hacerlo —perder clientes, perder reputación, perder datos— suele ser mucho más alto.
La clave es entender que escalar no es un proyecto que se hace una vez y se termina. Es una disciplina que se incorpora a la forma de construir software, y que empieza mucho antes de tener los mil usuarios: empieza cuando tomás la decisión consciente de construir para la escala que querés tener, no solo para la que tenés hoy.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →