Lección 01

Escalar no es optimizar

La confusión entre estas dos palabras es la razón por la que casi todo el mundo contesta mal la primera pregunta de una entrevista senior.

01Qué es

Optimizar es hacer lo mismo más rápido. Escalar es sostener el crecimiento sin tener que cambiar el modelo cada vez.

Piensa en una carretera. Optimizar es subir el límite de velocidad: llegas antes, pero caben los mismos coches. Escalar es añadir carriles: no vas más rápido, pero caben más. Y hay una tercera cosa, que es lo que de verdad se pregunta en una entrevista: saber cuál de las dos necesita el problema.

El error clásico: te dicen "la lista va lenta" y contestas "le puse memoización a cada elemento". Eso es optimizar. Si el problema es que hay 5.000 elementos puestos, memoizar no escala: sigues teniendo 5.000. Escalar es dejar de tenerlos.

La pregunta correcta

No es "¿cómo lo hago más rápido?". Es "¿qué se rompe primero cuando esto crece diez veces?". Todo lo demás es consecuencia de esa respuesta.

02Por qué sucede

Un sistema no se degrada de forma uniforme: se degrada por el recurso que se agota primero. Si tienes agua, gasolina y tiempo, el viaje lo corta lo que se acabe antes. En un navegador pasa igual, y los recursos son pocos y siempre los mismos.

Por eso la palabra "lento" no significa nada por sí sola. "Lento" puede ser: demasiadas piezas puestas (nodos), demasiado trabajo de una vez (hilo principal), demasiada memoria, o demasiadas idas y vueltas por la red. Son cuatro enfermedades distintas con cuatro tratamientos distintos, y casi nadie empieza preguntando cuál es.

Los cuatro ejes: cada uno se rompe en un sitio distinto 1 · DATOS Crece el número de filas o el tamaño se rompe: nodos, memoria, hilo palanca: virtualizar, worker 2 · USUARIOS Crece el tráfico y la concurrencia se rompe: primer pintado, servidor palanca: SSR, caché, CDN 3 · EQUIPO Crece el número de ingenieros y features se rompe: la coherencia palanca: fronteras, reglas en CI 4 · DOMINIO Crecen formatos, mercados, variantes se rompe: el if que crece palanca: datos, no código
Antes de proponer nada, identifica el eje. Un problema de datos no se arregla con caché, y un problema de equipo no se arregla con virtualización.

03Cómo se ataca

El método tiene cinco pasos y el orden importa. Si te saltas el primero, optimizas lo que no era; si te saltas el quinto, vuelves al mismo problema en seis meses.

  1. Cuello de botella. ¿Qué se rompe primero? Nombra el recurso.
  2. Medición. ¿Con qué número lo sé? Sin número no hay problema, hay una opinión.
  3. Palanca. Elige una de las cuatro y di qué cuesta.
  4. Lo que no harías. Descartar una opción razonable demuestra criterio.
  5. El siguiente límite. ¿Qué se rompe cuando esto crezca otra vez?

El quinto paso es el que casi nadie da y el que más se nota, porque demuestra que piensas en sistemas y no en tickets.

Optimizar mueve la recta; escalar le cambia la forma usuarios → costo optimizado: sigue creciendo igual escalado: la curva cambia de forma límite aceptable
La prueba de que escalaste no es que el número bajó: es que la curva dejó de ser una recta. Si al duplicar usuarios el costo se duplica, optimizaste.

La diferencia se ve mejor en código. Las dos versiones de abajo hacen "lo mismo" para el usuario, pero solo una deja de costar más cuando la lista crece:

// OPTIMIZAR: el mismo modelo, con menos trabajo por fila
const Fila = memo(function Fila({ dato }) {
  return <li>{dato.nombre}</li>
});                       // sigue habiendo 8.000 filas puestas

// ESCALAR: otro modelo — solo existe la ventana visible
const [scroll, setScroll] = useState(0);
const desde = Math.floor(scroll / ALTO);
const hasta = desde + filasVisibles + OVERSCAN;

return (
  <div style={{ height: datos.length * ALTO }}>      // el scroll miente
    {datos.slice(desde, hasta).map((dato) => (     // solo ~40 existen
      <Fila key={dato.id} dato={dato} />
    ))}
  </div>
);
Cómo distinguirlas de un vistazo

Si mañana llegan 80.000 filas en vez de 8.000, la primera versión se vuelve 10 veces más lenta. La segunda no se entera: el trabajo depende del tamaño de la ventana, no del tamaño de los datos. Esa es la prueba de que escalaste.

04Cómo diagnosticarlo

"Diagnosticar" aquí significa responder a una sola pregunta: ¿cuál de los cuatro recursos se está agotando? Se contesta con método, no con intuición.

HerramientaQué se miraCómo se ve el síntoma
DevTools › Performance Tareas largas y repintados Barras rojas de más de 50 ms; el frame rate cae a 10–15 fps
DevTools › Network Forma de la cascada y peso Una escalera de peticiones encadenadas, o 2 MB de JS antes del primer texto
Elements Cuántos nodos hay puestos Miles de elementos en el árbol; el scroll recalcula todo
Memory › heap snapshot Objetos que no se liberan El conteo de objetos "detached" crece entre dos tomas
Cuando no tienes herramientas

En una entrevista no vas a abrir DevTools. Razona desde los recursos: en un navegador solo se agotan cuatro cosas — nodos, tiempo del hilo principal, memoria y red; en un servidor, otras cuatro — conexiones, escrituras por segundo, tamaño de cola y costo de consulta.

Y dilo así: "Let me figure out which resource this is before I propose a fix." Eso convierte un "no sé" en método.

Para decirlo en la entrevista

“Scaling isn't making it faster. It's changing what breaks.”

“In a browser there are only four things to run out of: DOM nodes, main-thread time, memory, and network.”

“This gets us to about X. Past that, the model breaks and here's what I'd change.”

Comprueba que lo tienes

Cuatro preguntas. Al comprobar se marca la lección como completada.

Una tabla de 8.000 filas va lenta. Añades memo a cada fila y sigue igual de lenta. ¿Qué falla?

¿Cuál de estas cuatro frases describe una decisión de escalabilidad y no de optimización?

Tu app tarda 9 segundos en aparecer y el servidor responde en 40 ms. ¿Cuál de los cuatro recursos es el sospechoso?

¿Por qué el paso "¿qué se rompe después?" vale tanto en una entrevista?