Escalabilidad: cómo saber si tu sistema aguantará 10 veces más clientes

En este artículo

1. ¿Qué es la escalabilidad de un sistema?
2. ¿De qué depende que un sistema aguante?
3. Señales de que tu sistema no aguantará el crecimiento
4. Ejemplo: de 50 a 500 pedidos al día
5. Qué medir: velocidad, errores y capacidad
6. Cómo probar si aguantará: la prueba de carga
7. ¿Escalar siempre es caro?
8. Preguntas para tu proveedor
9. En resumen
10. Preguntas frecuentes

«¿Y si mañana vendo diez veces más, el sistema aguanta?» Es una pregunta que casi ningún dueño de empresa hace al contratar un software, y que todos se hacen el día que el sistema se cae en plena campaña. La buena noticia es que la escalabilidad se puede revisar antes, con preguntas concretas y una prueba sencilla.

Aquí explicamos qué es la escalabilidad sin tecnicismos, de qué depende, las señales de que tu sistema no aguantará, qué preguntarle a tu proveedor y cómo probarlo antes del próximo pico. En CONIT administramos webs, tiendas y sistemas de empresas de todo el Perú en servidor propio en la nube, y vemos cada temporada cómo se comporta cada uno cuando el tráfico sube.

¿Qué es la escalabilidad de un sistema?

Es la capacidad de un sistema de atender más usuarios, pedidos y datos sin volverse lento ni caerse, y sin tener que construirlo de nuevo. Un sistema escalable crece ampliando recursos o mejorando piezas puntuales; uno que no lo es te obliga a rehacerlo justo cuando el negocio despega.

Hay dos formas de escalar:

Para la mayoría de pymes, escalar verticalmente alcanza durante años. La horizontal se vuelve necesaria con volúmenes muy grandes o cuando no puedes permitirte ni un minuto de caída.

¿De qué depende que un sistema aguante?

Depende de cuatro piezas. Si una falla, las otras no la salvan:

1. El servidor. Su memoria, procesador y disco, y sobre todo si se puede ampliar sin rehacer nada. Un hosting compartido barato comparte recursos con cientos de sitios; un servidor dedicado o una nube bien dimensionada te da margen.
2. La base de datos. Es el cuello de botella más común. Una tabla sin índices funciona con mil registros y se arrastra con un millón. Ver qué base de datos usa tu sistema.
3. El código. Un reporte que recorre todas las ventas de la historia cada vez que alguien abre el panel, o una pantalla que hace cien consultas cuando bastaba una, multiplican la carga.
4. Los servicios externos. Pasarelas, correo, WhatsApp, facturación electrónica: tienen sus propios límites. La API de WhatsApp, por ejemplo, empieza con un límite de 250 usuarios únicos por día para mensajes iniciados por la empresa y lo amplía por etapas (Meta, revisado el 10 de octubre de 2026).

Señales de que tu sistema no aguantará el crecimiento

Revisa si alguna de estas te suena:

• Se pone lento en horas punta (cierre de mes, inicio de clases, campaña) y vuelve a la normalidad después.
• Los reportes tardan minutos o hay que pedirlos «en la noche para no trabar».
• Se cayó en la última campaña o en un día de mucha venta.
• El proveedor dice que «hay que comprar un servidor más grande» cada pocos meses, sin explicar por qué.
• Las imágenes y archivos se guardan dentro del mismo servidor y el disco se llena.
• Nadie mide cuánto tarda una página ni cuántos errores hay.

Una o dos señales no significan que haya que rehacer el sistema. Significan que hay que medir dónde está el problema.

Ejemplo: de 50 a 500 pedidos al día

Pongamos una tienda virtual de productos para mascotas que recibe 50 pedidos diarios y lanza una campaña que podría llevarla a 500.

Con 50 pedidos, todo parece bien. Con 500, aparecen problemas en lugares inesperados: el buscador del catálogo hace una consulta pesada cada vez que alguien escribe una letra; el correo de confirmación se envía en el mismo momento del pago y, si el servicio de correo tarda, la pantalla de pago se queda «pensando»; las fotos de productos pesan varios megas cada una y en celular la página tarda en cargar; y el reporte de ventas que el gerente abre cada hora recorre todos los pedidos desde el primer día.

Ninguno de estos problemas se resuelve solo comprando un servidor más grande. Se resuelven con un índice en la tabla de productos, enviando los correos en segundo plano, optimizando las imágenes y guardando un resumen diario para el reporte. Con eso, el mismo servidor aguanta la campaña con margen. Por eso el primer paso siempre es medir.

Qué medir: velocidad, errores y capacidad

No se puede mejorar lo que no se mide. Estos son los indicadores básicos:

• Tiempo de carga en celular. Google considera buena una carga del contenido principal en 2.5 segundos o menos, medida en el 75 % de las visitas (web.dev). Puedes revisarlo gratis con PageSpeed Insights.
• Tiempo de respuesta de las operaciones clave: buscar, agregar al carrito, pagar, generar un reporte.
• Errores por hora, sobre todo en horas punta.
• Uso del servidor: memoria, procesador y disco, con alertas antes de llegar al límite.

Pide a tu proveedor que estos números se revisen cada mes, no solo cuando hay una queja. Es parte de un buen mantenimiento de software.

Lo que hacemos en CONIT

Construimos sistemas a medida y páginas web para empresas de todo el Perú, alojados en servidor propio en la nube con caché, copias diarias y monitoreo, y revisamos cada sitio antes de las temporadas fuertes de sus clientes. Mira tiendas y sistemas de reservas en marcha en nuestros casos de turismo o conoce el servicio de sistemas a medida.

Cómo probar si aguantará: la prueba de carga

Una prueba de carga simula muchos usuarios a la vez haciendo lo que harían de verdad, y mide cuándo el sistema empieza a responder lento o a fallar. Se hace así:

1. Define tu pico esperado. Por ejemplo: «el día del lanzamiento esperamos 500 personas a la vez buscando y 50 pagando por minuto».
2. Elige los recorridos que se van a simular: entrar, buscar, ver ficha, comprar.
3. Prueba en un entorno de prueba idéntico al real, nunca sobre tus clientes. Hay herramientas gratuitas de software libre para esto, como Grafana k6.
4. Sube la carga por escalones hasta pasar tu pico con margen (por ejemplo, el doble).
5. Anota dónde se rompe: ¿la base de datos, el servidor, la pasarela?
6. Corrige y repite.

Hazla semanas antes de una campaña, no la víspera. Y no olvides avisar a los servicios externos si tu prueba los toca.

¿Escalar siempre es caro?

No necesariamente. Muchas mejoras de rendimiento cuestan poco comparadas con un servidor más grande:

El orden importa: primero medir, luego corregir lo barato y, recién después, ampliar infraestructura. Lo comparamos en nube o servidor propio para el sistema de tu empresa.

Preguntas para tu proveedor

Antes de contratar o de una campaña grande, pregunta:

• ¿En qué tipo de servidor está el sistema y cómo se amplía?
• ¿Qué pasa si se cae: hay monitoreo, quién se entera y en cuánto tiempo se levanta?
• ¿Las imágenes, videos y archivos están dentro del servidor o en un servicio aparte?
• ¿Se hizo alguna prueba de carga? ¿Con cuántos usuarios simultáneos?
• ¿Qué servicios externos usa y qué límites tienen?

En resumen

• La escalabilidad es la capacidad de atender más clientes y datos sin volverse lento ni rehacer el sistema.
• Depende del servidor, la base de datos, el código y los servicios externos.
• Las alarmas son lentitud en horas punta, reportes de minutos y caídas en campañas.
• Mide velocidad en celular, errores y uso del servidor cada mes, no solo cuando hay quejas.
• Antes de un pico, haz una prueba de carga y corrige primero lo barato: índices, caché e imágenes.

Preguntas frecuentes

¿Qué significa que un sistema sea escalable?

Que puede atender más usuarios, más operaciones y más datos ampliando sus recursos, sin volverse lento y sin tener que construirlo de nuevo. Un sistema escalable crece agregando servidor o mejorando partes puntuales; uno que no lo es obliga a rehacerlo cuando el negocio crece.

¿Cómo sé si mi sistema aguantará una campaña grande?

Con una prueba de carga: un ensayo que simula muchos usuarios a la vez haciendo lo que harían en la campaña (entrar, buscar, comprar) y mide tiempos de respuesta y errores. Hazla en un entorno de prueba, semanas antes, y con un margen por encima del pico que esperas.

¿Escalar un sistema siempre significa pagar un servidor más grande?

No siempre. Muchas veces la lentitud viene de una consulta mal hecha a la base de datos, de imágenes muy pesadas o de un proceso que se repite sin necesidad. Corregir eso puede rendir más que duplicar el servidor. Primero se mide dónde está el cuello de botella, luego se decide.

¿La nube escala sola?

La nube permite ampliar recursos rápido y, en algunos servicios, hacerlo de forma automática según la demanda. Pero si el sistema no está preparado (por ejemplo, guarda archivos en un solo servidor o tiene consultas lentas), más servidores no resuelven el problema. Escalar es una mezcla de infraestructura y de cómo está hecho el sistema.

¿Cuándo conviene pensar en la escalabilidad?

Desde el diseño, pero sin exagerar. Para un sistema nuevo basta con buenas prácticas: base de datos bien estructurada, servidor que se pueda ampliar y código ordenado. Construir desde el día uno para millones de usuarios que todavía no tienes encarece el proyecto sin necesidad.