No puedes escalar lo que no puedes medir

El título suena a regaño, pero es una realidad que he visto repetirse: software que crece sin medirse desde el inicio termina siendo imposible de mantener.

Es como un niño que nunca va al médico, todo parece bien hasta que no lo está, y entonces ya es tarde para prevenir.

El software debería medirse desde su etapa inicial. No con herramientas enterprise ni sobre-ingeniería, con lo mínimo necesario para saber cómo está tu sistema internamente.

Para eso diseñé un modelo de fases basado en 4 recursos fundamentales que reflejan cómo se está comportando la carga de tu sistema:

• CPU
• RAM
• Disco
• Red

Fase 1: Escalar verticalmente (exprimir primero)

Antes de agregar más máquinas, exprime la que tienes. Escalar verticalmente (más CPU/RAM a la misma instancia) te da dos cosas:

• Una perspectiva real de cuánto aguanta tu sistema antes de necesitar complejidad adicional.
• Una referencia inicial de costos: sabes cuánto pagarás cuando eventualmente necesites más instancias.

No tiene sentido distribuir un sistema que no has medido en una sola máquina. Primero entiende dónde está el cuello de botella.

Fase 2: Entiende qué parte del sistema está gritando

Antes de escalar horizontalmente, identifica exactamente dónde duele:

• CPU al 100%: Primero identifica la causa. Puede ser un algoritmo ineficiente, consultas costosas, serialización, compresión, cifrado o simplemente una carga legítima que ya superó la capacidad del nodo. Optimiza cuando sea posible; si el problema es capacidad, entonces escala CPU.
• RAM saturada: Analiza por qué la memoria está creciendo. Puede ser una caché demasiado grande, un memory leak, consultas que cargan más datos de los necesarios o simplemente un patrón de uso esperado. La memoria alta no siempre significa que exista un problema.
• Disco lento: Revisa el patrón de I/O. Puede ser la base de datos, escritura intensiva de logs o simplemente un volumen que ya no da más. Antes de cambiar infraestructura, entiende qué está generando ese tráfico.
• Red saturada: No solo revises el ancho de banda. También analiza latencia, cantidad de llamadas entre servicios, tamaño de payloads y tráfico innecesario. Muchas veces el problema no es la red, sino cómo la estamos utilizando.

Hay una métrica que normalmente olvidamos y que termina siendo la más importante: la latencia. El usuario no sabe cuánta CPU consume tu sistema ni cuánta RAM tiene. Lo único que percibe es cuánto tarda en responder. Por eso vale la pena medir P50, P95 y P99 además del uso de recursos.

Solo cuando agotaste la capacidad vertical del nodo y ya identificaste el cuello de botella real, pasas a escalar horizontalmente, es decir, agregar más nodos. No antes.

Escalar horizontalmente sin entender por qué un solo nodo dejó de ser suficiente es, muchas veces, tirar dinero al problema en lugar de resolver la causa.

Fase 3: Escalar horizontalmente (distribuir la carga)

Ya exprimiste el nodo, ya identificaste los cuellos de botella. Ahora sí: distribuyes.

Pero “escalar horizontalmente” no es una sola cosa. Hay varios ejes.

Escalar la base de datos

• Replicación: múltiples copias para distribuir lecturas (líder-seguidor, multi-líder o sin líder).
• Particionado: dividir los datos en shards para que ningún nodo cargue con todo.

Escalar la aplicación

• Múltiples instancias detrás de un load balancer.
• Auto Scaling basado en métricas (CPU, requests por segundo, etc.).
• Stateless por diseño. Si tu aplicación guarda estado en memoria, escalar será mucho más difícil.

Escalar la red

• CDN para assets y contenido estático.
• Rate limiting para proteger el backend.
• Compresión y optimización de payloads.

Escalar el sistema como un todo

• Desacoplar servicios (de monolito a microservicios o, al menos, servicios independientes).
• Arquitecturas orientadas a eventos para reducir el acoplamiento entre servicios.
• Queues para absorber picos de carga sin perder solicitudes.

El objetivo no es tener más servidores. Es darle al usuario final una mejor experiencia y al sistema la capacidad de crecer sin romperse.

Conclusión

Escalar no es agregar servidores. Es un proceso que empieza midiendo, sigue identificando dónde duele y termina distribuyendo con intención.

La secuencia importa:

• Mide: si no sabes cómo está tu sistema, cualquier decisión será a ciegas.
• Exprime: escala verticalmente antes de distribuir.
• Identifica: entiende qué componente es realmente el cuello de botella.
• Distribuye: escala horizontalmente solo aquello que realmente necesita ser escalado.

La mayoría de sistemas no necesitan Kubernetes ni veinte microservicios. Necesitan algo mucho más simple: entender cómo se comportan. Cuando puedes medir tu sistema, dejas de tomar decisiones por intuición y empiezas a hacerlo con evidencia.

En el siguiente post voy a entrar en cómo implementar observabilidad desde cero para medir todo esto en la práctica.