The latest articles on DEV Community by Luis (@luis_d301c3ab18fcfad97ba1). https://dev.to/luis_d301c3ab18fcfad97ba1 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4009841%2Fa370349b-ceeb-4fa5-ac74-99132c33ee99.png https://dev.to/luis_d301c3ab18fcfad97ba1 en Luis Tue, 30 Jun 2026 16:33:52 +0000 https://dev.to/luis_d301c3ab18fcfad97ba1/no-puedes-escalar-lo-que-no-puedes-medir-284h https://dev.to/luis_d301c3ab18fcfad97ba1/no-puedes-escalar-lo-que-no-puedes-medir-284h <p>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.</p> <p>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.</p> <p>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.</p> <p>Para eso diseñé un modelo de fases basado en 4 recursos fundamentales que reflejan cómo se está comportando la carga de tu sistema:</p> <ul> <li>CPU</li> <li>RAM</li> <li>Disco</li> <li>Red</li> </ul> <h2> Fase 1: Escalar verticalmente (exprimir primero) </h2> <p>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:</p> <ul> <li>Una perspectiva real de cuánto aguanta tu sistema antes de necesitar complejidad adicional.</li> <li>Una referencia inicial de costos: sabes cuánto pagarás cuando eventualmente necesites más instancias.</li> </ul> <p>No tiene sentido distribuir un sistema que no has medido en una sola máquina. Primero entiende dónde está el cuello de botella.</p> <h2> Fase 2: Entiende qué parte del sistema está gritando </h2> <p>Antes de escalar horizontalmente, identifica exactamente dónde duele:</p> <ul> <li>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.</li> <li>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.</li> <li>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.</li> <li>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.</li> </ul> <p>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.</p> <p>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.</p> <p>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.</p> <h2> Fase 3: Escalar horizontalmente (distribuir la carga) </h2> <p>Ya exprimiste el nodo, ya identificaste los cuellos de botella. Ahora sí: distribuyes.</p> <p>Pero “escalar horizontalmente” no es una sola cosa. Hay varios ejes.</p> <p><strong>Escalar la base de datos</strong></p> <ul> <li>Replicación: múltiples copias para distribuir lecturas (líder-seguidor, multi-líder o sin líder).</li> <li>Particionado: dividir los datos en shards para que ningún nodo cargue con todo.</li> </ul> <p><strong>Escalar la aplicación</strong></p> <ul> <li>Múltiples instancias detrás de un load balancer.</li> <li>Auto Scaling basado en métricas (CPU, requests por segundo, etc.).</li> <li>Stateless por diseño. Si tu aplicación guarda estado en memoria, escalar será mucho más difícil.</li> </ul> <p><strong>Escalar la red</strong></p> <ul> <li>CDN para assets y contenido estático.</li> <li>Rate limiting para proteger el backend.</li> <li>Compresión y optimización de payloads.</li> </ul> <p><strong>Escalar el sistema como un todo</strong></p> <ul> <li>Desacoplar servicios (de monolito a microservicios o, al menos, servicios independientes).</li> <li>Arquitecturas orientadas a eventos para reducir el acoplamiento entre servicios.</li> <li>Queues para absorber picos de carga sin perder solicitudes.</li> </ul> <p>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.</p> <p><strong>Conclusión</strong></p> <p>Escalar no es agregar servidores. Es un proceso que empieza midiendo, sigue identificando dónde duele y termina distribuyendo con intención.</p> <p>La secuencia importa:</p> <ul> <li>Mide: si no sabes cómo está tu sistema, cualquier decisión será a ciegas.</li> <li>Exprime: escala verticalmente antes de distribuir.</li> <li>Identifica: entiende qué componente es realmente el cuello de botella.</li> <li>Distribuye: escala horizontalmente solo aquello que realmente necesita ser escalado.</li> </ul> <p>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.</p> <p>En el siguiente post voy a entrar en cómo implementar observabilidad desde cero para medir todo esto en la práctica.</p>