Por qué una solución que funciona con 10 usuarios puede fallar con 1.000

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.

La analogía del restaurante

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.

Por qué diez y mil no son lo mismo: los tres problemas que aparecen con la escala

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.

El problema de la concurrencia

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.

El problema de los datos

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.

El problema de la infraestructura

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.

Por qué "agregar más potencia" no siempre funciona

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.

Cómo cambian las prioridades de desarrollo con la escala

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.

Señales de que tu solución actual no va a sobrevivir al crecimiento

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:

• Todo está en un solo servidor. La aplicación, la base de datos, los archivos y los backups comparten la misma máquina. Con baja demanda funciona; con alta demanda, los componentes compiten entre sí y todo se degrada.
• Las tareas pesadas se ejecutan mientras el usuario espera. Por ejemplo, generar un reporte extenso o procesar una importación de datos bloquea la aplicación hasta que termina. Con diez usuarios, la espera es de unos segundos. Con mil, alguien lanza un reporte y todos los demás usuarios quedan esperando a que termine.
• No hay un mecanismo para detectar y responder a fallas automáticamente. Si el servidor se cae a las tres de la mañana, nadie se entera hasta las nueve cuando llega el primer empleado. Para entonces, ya pasaron seis horas de servicio interrumpido —y los usuarios que intentaron entrar durante la madrugada se fueron con una mala experiencia.
• Los datos no están respaldados de forma consistente y automatizada. Un backup que depende de que alguien se acuerde de hacerlo manualmente cada viernes es un incidente esperando a ocurrir.

Cuándo es el momento de rediseñar

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:

• Empezás a tener clientes que dependen del sistema para operar su propio negocio —y una caída tuya los afecta a ellos.
• El volumen de datos crece al punto de que las operaciones que antes eran instantáneas ahora tienen una demora perceptible.
• Detectás las señales descritas en el artículo sobre cómo saber si tu aplicación está preparada para crecer —especialmente errores intermitentes y lentitud en horas pico.

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.