Software escalable: cómo construir un sistema que aguante el crecimiento

«Necesitamos una solución escalable a nivel global» es una de las frases que más nos dicen y una de las que peor se entienden. Escalar no es «que aguante mucha gente»: es que el sistema pueda crecer sin que el coste, la complejidad y los fallos crezcan más rápido que tu negocio. Y se decide al principio, en cuatro o cinco elecciones de arquitectura que después son carísimas de deshacer.

Lo esencial

• Escalable no significa «grande»: significa que duplicar la carga no duplica los problemas ni triplica la factura.
• El 90% de los cuellos de botella reales están en la base de datos, no en el servidor de aplicación. Ahí es donde hay que mirar primero.
• Lo caro de deshacer no es el código: es el modelo de datos y el hecho de que el sistema guarde estado donde no debe.
• No optimices para un tráfico que no tienes. Construir para millones de usuarios cuando tienes cien es la forma más elegante de arruinarte antes de llegar.

Qué significa realmente «escalable»

Un sistema es escalable si puedes atender el doble de carga poniendo aproximadamente el doble de recursos —y sin reescribirlo. Suena obvio y casi ningún sistema mal diseñado lo cumple: llega un punto en que añadir más máquinas no mejora nada, porque todas chocan contra el mismo cuello de botella.

La distinción clásica es entre escalar en vertical (poner una máquina más potente) y escalar en horizontal (poner más máquinas trabajando en paralelo). La primera es fácil, inmediata y tiene un techo duro: llega un momento en que no hay máquina más grande, o cuesta un disparate. La segunda no tiene techo práctico, pero exige que el software esté diseñado para ello. Y ese diseño no se añade después: se elige al empezar.

Las decisiones que son caras de deshacer

1. El modelo de datos

Es la decisión que más condiciona todo lo demás, y la que más gente toma sin pensar. Cómo estructuras la información, qué se relaciona con qué y qué consultas vas a necesitar determina si dentro de dos años una operación tarda 50 milisegundos o 12 segundos. Cambiar el modelo de datos con el sistema en producción y con datos reales dentro es de las cosas más caras y arriesgadas que existen en este oficio.

2. Guardar estado donde no toca

Si tu aplicación guarda información de la sesión del usuario en la memoria del servidor que le atendió, ya no puedes repartir usuarios entre varios servidores sin romper cosas. Las aplicaciones que escalan bien son sin estado: cualquier petición puede ir a cualquier servidor porque el estado vive en un sitio compartido. Es una decisión de diseño barata al principio e incómoda de retrofitear.

3. Procesar en el momento lo que podría esperar

Generar un informe pesado, mandar 5.000 correos o procesar un vídeo mientras el usuario espera convierte cada pico de uso en una caída. La alternativa —encolar ese trabajo y procesarlo aparte— es sencilla si se piensa desde el principio y una cirugía si se añade luego.

4. Ignorar la latencia si tus usuarios están lejos

Aquí es donde entra lo «global» de verdad. Si tu servidor está en Fráncfort y tus usuarios en Chile, la física manda: cada ida y vuelta cuesta cientos de milisegundos y no hay código que lo arregle. Se resuelve acercando los datos al usuario —con una red de distribución de contenidos (CDN), réplicas regionales y caché— y diseñando para tolerar esa distancia. Que tu sistema sea global no es un tema de capacidad: es un tema de geografía.

5. No poder ver qué está pasando

Un sistema que crece sin métricas, trazas ni alertas es un sistema que se romperá de una forma que nadie sabrá explicar. La observabilidad no escala nada por sí misma, pero sin ella no puedes saber qué hay que escalar —y acabas comprando máquinas a ciegas.

El error contrario: escalar lo que no hace falta

Todo lo anterior tiene un reverso, y lo vemos tanto como el problema opuesto: equipos que montan una arquitectura de microservicios distribuida en tres continentes para servir a doscientos usuarios. Se llama sobreingeniería, y sale carísima: multiplica la complejidad, ralentiza cada cambio, dispara la factura de cloud y consume el tiempo del equipo en mantener andamiaje en lugar de construir producto.

La regla honesta: diseña para que se pueda escalar, pero no escales hasta que lo necesites. Un sistema bien construido, sin estado, con un modelo de datos sensato y con las tareas pesadas fuera del camino crítico, aguanta muchísimo más de lo que la mayoría de negocios va a necesitar nunca —y el día que haga falta más, se añade sin reescribir nada.

La arquitectura correcta no es la que soporta un millón de usuarios. Es la que soporta los que tienes hoy y no te impide llegar al millón.

La factura de cloud: el efecto secundario que nadie avisa

Escalar mal no solo se paga en caídas: se paga cada mes. Un sistema ineficiente que resuelve el problema «poniendo más máquinas» funciona —y te deja una factura que crece más rápido que tus ingresos, hasta que un día alguien la mira y descubre que la infraestructura se come el margen.

Cómo lo abordamos

La escalabilidad no es una fase posterior del proyecto: son decisiones que tomamos desde el primer día del desarrollo a medida, aunque el sistema arranque pequeño. Modelo de datos pensado para las consultas reales, aplicación sin estado, trabajo pesado fuera del camino del usuario y observabilidad desde el principio. No cuesta más construirlo así; cuesta muchísimo más arreglarlo después.

Cuando el crecimiento ya está encima —o cuando la factura de cloud se ha desbocado— el trabajo es distinto: hay que medir dónde está el cuello de botella real antes de tocar nada. Eso es arquitectura cloud, y a menudo empieza con una auditoría que diga qué está pasando de verdad. Y si el sistema lo mantiene un tercero que te dice que «hay que migrarlo todo», conviene tener criterio propio antes de firmar: es justo lo que aporta un CTO externo.