1. Presentación del módulo: cuando el workflow es el cuello de botella

Descripción

Al terminar esta lección vas a poder explicar por qué la respuesta a "mi automatización va lenta" casi nunca es "necesito un servidor más grande", vas a conocer el caso que va a guiar todo el módulo —un workflow de Terra Market que pasó de tardar 40 segundos a tardar 11 minutos sin que nadie tocara el servidor—, y vas a tener el mapa completo de las ocho lecciones y del orden en que se atacan las cosas.

Esto importa por una razón de dinero y de tiempo. Cuando un workflow se pone lento, el instinto de casi todo el mundo es el mismo: pedir más máquina. Es el reflejo más caro que existe en operaciones, porque en la enorme mayoría de los casos la máquina no es el problema. El problema es que el workflow hace trescientas llamadas a una API cuando podría hacer una, o arrastra en memoria un archivo de veinte megabytes que ni siquiera va a usar, o intenta procesar diez mil registros de golpe cuando debería tomarlos de a doscientos. Comprar un servidor más grande para uno de esos problemas es como comprar un camión más grande porque no sabes que estás cargando piedras que no vas a usar. El camión nuevo también va a ir lento, y ahora además pagas por él cada mes.

Conexión con el módulo: esta lección no configura nada todavía. Es el mapa y el contrato de trabajo. Aquí defines el problema (por qué el workflow, y no la infraestructura, es lo primero que se mira), reencuentras a Terra Market —la empresa que ya conoces del Módulo 2, con sus cuatro sistemas y sus dieciocho workflows— y recibes el orden en que las lecciones 2 a 8 van a atacar la lentitud. Una nota de límite desde ya, y es la razón por la que este módulo se rediseñó: aquí no se monta el modo cola (queue mode), ni Redis, ni workers, ni se escala la instancia. Eso es otra guía entera, y la lección 7 es justamente la frontera que te dice cuándo cruzar a ella. Aquí se trabaja sobre el workflow.

Dos personas frente al mismo semáforo en rojo

Imagina dos personas que manejan al trabajo por la misma avenida, y las dos llevan tres semanas quejándose de que el trayecto se volvió eterno. Antes tardaban veinte minutos; ahora tardan una hora.

La primera persona concluye que el problema es su carro. "Está viejo, le falta potencia, por eso voy tan lento." Compra un carro nuevo, más caro, con más caballos de fuerza. El lunes siguiente hace exactamente el mismo trayecto en el carro nuevo... y tarda una hora. Porque el carro nunca fue el problema: hay una obra en la avenida que reduce tres carriles a uno, y no hay motor en el mundo que te haga avanzar más rápido en una fila que no se mueve.

La segunda persona, antes de gastar un peso, hace algo aburrido: un día se fija dónde exactamente pierde el tiempo. Sale con el cronómetro y anota. Descubre que los primeros diez minutos fluyen bien, que se le van cuarenta minutos parada en el mismo tramo de dos cuadras, y que el resto del camino también fluye. Ahí está todo el problema, concentrado en dos cuadras. Con ese dato, la solución aparece sola: hay una calle paralela que se salta justo ese tramo. Al día siguiente desvía por ahí y vuelve a tardar veinticinco minutos. En el mismo carro viejo.

La diferencia entre las dos personas no es el presupuesto ni la inteligencia. Es que una midió y la otra adivinó. Y adivinar en rendimiento tiene una trampa cruel: casi siempre te lleva a gastar en el lugar equivocado, porque el instinto humano frente a la lentitud es "más potencia", y la lentitud casi nunca se cura con más potencia. Se cura encontrando el tramo de dos cuadras.

Este módulo entero es sobre ser la segunda persona. Y la buena noticia es que en n8n el cronómetro ya viene puesto: cada ejecución registra cuánto tardó cada nodo. Solo hay que aprender a leerlo, que es la lección 2.

Ejemplo trabajado: los 40 segundos que se volvieron 11 minutos

Vamos a mirar el caso real que abre el módulo, porque cada lección de aquí en adelante va a volver a él.

El workflow. inventory-update es uno de los tres protagonistas de Terra Market que ya conoces. Cada 15 minutos toma el stock actualizado del erp y lo empuja a storefront, para que la tienda no venda café que ya se acabó. Cada corrida mueve unos 300 sku —los códigos de producto del catálogo—. Es el workflow rutinario y tolerante: si una corrida falla, la siguiente corrige. Nunca dio problemas.

El síntoma. Hace tres meses, ese workflow terminaba en unos 40 segundos. Cómodo: corre cada 15 minutos, así que tenía catorce minutos y veinte segundos de sobra antes de la siguiente corrida. Esta semana, la persona de operaciones nota que la lista de ejecuciones se ve rara: las corridas de inventory-update están tardando 11 minutos. Con los mismos 300 sku. Nadie tocó el servidor de n8n —ni más RAM, ni menos, ni un cambio de versión—. Y hay un detalle que asusta: si el workflow tarda 11 minutos y corre cada 15, ya casi se está solapando consigo mismo. Dos o tres minutos más de lentitud y la corrida de las 14:15 no va a haber terminado cuando arranque la de las 14:30.

El reflejo caro. La primera reacción del equipo es la de la primera persona del semáforo: "el volumen creció, n8n se quedó chico, hay que subirle la máquina". Alguien ya está cotizando un VPS más grande. Si Terra Market hace eso, va a pagar más cada mes y el workflow va a seguir tardando 11 minutos, porque —como vamos a descubrir— el servidor de n8n nunca estuvo ocupado durante esos 11 minutos. Estuvo esperando.

Lo que se descubre al medir. En la lección 2 vas a abrir una ejecución de inventory-update y leer los tiempos por nodo. Adelanto el resultado, porque es el corazón del módulo:

Schedule Trigger ........... 0.0 s
ERP: get sku list .......... 1.5 s
Loop: GET stock (×300) ..... 630   s   ◄── aquí está TODO
Code: transform ............ 3.0 s
Push to storefront (×300) .. 25   s
Postgres: log .............. 0.5 s

Casi todo el tiempo —diez minutos y medio de los once— se va en un solo lugar: un bucle que llama al erp una vez por cada sku. Trescientas llamadas, una tras otra. Y hay un segundo dato que cambia todo: durante esas trescientas llamadas, el servidor de n8n no está trabajando, está esperando la respuesta del erp. El procesador está de brazos cruzados. Ponerle un procesador más rápido a algo que está esperando el correo no hace que el correo llegue antes.

Entonces, ¿por qué antes tardaba 40 segundos y ahora 11 minutos, si son los mismos 300 sku y las mismas 300 llamadas? Porque la que cambió fue la otra punta. El catálogo del erp creció mucho en estos meses, y cada consulta individual, que antes respondía en unos 130 milisegundos, ahora responde en unos 2 segundos. La cuenta es despiadada:

• Antes: 300 llamadas × 0,13 s ≈ 39 segundos. "Cuarenta segundos."
• Ahora: 300 llamadas × 2,1 s ≈ 630 segundos. "Once minutos."

El workflow siempre estuvo diseñado igual de mal: trescientas llamadas de a una. Lo que pasó es que ese mal diseño estaba escondido detrás de una API rápida, y en cuanto la API se puso lenta, el diseño quedó a la vista. Es el patrón más común de todos: la lentitud no la causó un cambio; la reveló.

Qué esperar del arreglo. No te voy a contar el final todavía, pero sí el rumbo. El erp —como muchas APIs— ofrece una operación para pedir el stock de varios sku de un solo golpe. Si en vez de trescientas llamadas de una hacemos unas pocas llamadas de a cien, el tiempo se desploma. En la lección 5 y en el proyecto de la lección 8 vas a ver inventory-update bajar de 11 minutos a unos 13 segundos —más rápido incluso que los 40 originales—, sin haber tocado el servidor ni una sola vez. Ese es el clímax del módulo, y es la prueba de la tesis: el arreglo estaba en el workflow.

Fíjate en lo que quiero que te lleves de este ejemplo, porque es la forma de pensar de todo lo que sigue:

	Lo que hizo el instinto	Lo que hizo la evidencia
Diagnóstico	"n8n se quedó chico"	"un nodo hace 300 llamadas esperando al ERP"
Solución propuesta	Comprar un servidor más grande	Hacer pocas llamadas en vez de muchas
Costo	Más caro cada mes, para siempre	Una tarde de trabajo, una sola vez
Resultado en el workflow	Sigue tardando 11 minutos	Tarda 13 segundos

Por qué "más máquina" es casi siempre la respuesta equivocada

Vale la pena entender por qué el reflejo de comprar servidor falla tan seguido, porque entenderlo te vacuna contra él.

El tiempo que tarda un workflow se reparte, a grandes rasgos, en tres cubetas distintas, y solo una de las tres se arregla con más máquina:

Tiempo de cómputo. Es el tiempo en que el procesador de n8n está de verdad haciendo algo: recorriendo una lista de diez mil elementos, transformando textos, calculando totales. Esta cubeta sí se beneficia de un procesador más rápido. Pero en la vida real de los workflows es, casi siempre, la cubeta más pequeña. n8n rara vez está haciendo cálculos pesados; está moviendo datos entre sistemas.

Tiempo de espera de red. Es el tiempo en que n8n mandó una petición a otro sistema —el erp, el carrier, una base de datos— y está parado esperando la respuesta. Durante esa espera, el procesador no hace nada útil. Esta es, en la mayoría de los workflows de integración como los de Terra Market, la cubeta más grande con diferencia. Y —este es el punto— un servidor más rápido no la reduce ni un milisegundo. Si el erp tarda 2 segundos en responder, tarda 2 segundos tengas el servidor que tengas. Lo único que la reduce es hacer menos esperas (menos llamadas) o esperas más cortas (una API más rápida, que no controlas).

Tiempo de cola. Es el tiempo en que la ejecución ni siquiera empezó: está formada, esperando su turno porque la instancia está ocupada con otras. Esta cubeta es especial, porque es la única que sí es un problema de capacidad de la instancia y no del workflow. Cuando esta cubeta es la que domina —cuando tus workflows pasan más tiempo esperando turno que ejecutándose— es la señal de que ya no es un problema de diseño, sino de infraestructura. Esa es exactamente la frontera de la lección 7.

La razón de fondo por la que "más máquina" falla es que la gente compra para la primera cubeta (cómputo) un problema que casi siempre vive en la segunda (espera de red). El caso de inventory-update es el ejemplo perfecto: sus once minutos son todos espera de red. Un servidor diez veces más potente lo dejaría en once minutos, porque el cuello nunca fue el músculo de n8n, fue la cantidad de veces que se para a esperar al erp.

Este módulo, dicho en una frase, es: aprende a ver en cuál de las tres cubetas se te va el tiempo, y arregla esa, no la que el instinto quiere arreglar.

Terra Market: recordatorio rápido

Trabajamos sobre la misma empresa inventada de toda la guía, así que si ya vienes del Módulo 2 esto te va a sonar. Si llegaste directo aquí, este es el escenario en tres párrafos.

Terra Market es un marketplace latinoamericano mediano —café de origen, textiles, artesanía— con unas 60 personas y clientes en México, Colombia, Chile y España. Tú eres la persona de automatización: cuando algo se rompe o se pone lento, es tu teléfono el que suena. La empresa tiene 18 workflows publicados en n8n que hacen en conjunto unas 4.000 ejecuciones al día, y n8n es el pegamento entre cuatro sistemas:

Sistema	Qué es	Su carácter
storefront	La tienda en línea	Confiable; a veces dispara el mismo evento dos veces
erp	Inventario, precios, pedidos, facturación	API REST con límite de peticiones por minuto; lento en horas pico
carrier	El transportista (andes-express)	El más inestable; se cae sin avisar
ops	Un PostgreSQL interno del equipo	Estable; es "nuestra" base

Y hay dos canales de Slack donde el equipo se entera de las cosas: #ops-alerts para lo urgente y #ops-daily para lo rutinario.

De los dieciocho workflows trabajamos a fondo con tres, que son las tres personalidades distintas que un workflow tiene en producción:

• order-sync — El crítico. Un cliente compra, se valida el pedido, se crea en el erp. Unas 1.200 ejecuciones/día. Cada ejecución es única e irrepetible: si una se pierde, ese pedido no existe para el almacén.
• inventory-update — El rutinario, y el protagonista de este módulo. Cada 15 minutos empuja stock del erp a storefront. Unas 96 ejecuciones/día, pero cada una mueve ~300 sku. Es tolerante a un fallo aislado, pero es el que se puso lento.
• shipment-notify — El visible. Avisa al cliente por correo cuando cambia el estado de su envío. Unas 2.500 ejecuciones/día; el de mayor volumen.

El item canónico que viste en el Módulo 2 —el pedido TM-48213 con su order_id, su customer_email, su shipping y su lista de items— sigue siendo el mismo. En este módulo, además, vas a mirar mucho la lista de sku que procesa inventory-update, que es donde vive el problema de rendimiento.

Una nota honesta, la misma de siempre: Terra Market es inventada, y sus números —60 personas, 18 workflows, 40 segundos, 11 minutos— son hipótesis razonables para practicar, no mediciones de un sistema real. Cuando optimices un workflow tuyo, los números van a ser otros. Lo que se transfiere es la forma de encontrarlos y de leerlos.

El mapa del módulo: atacar en orden de impacto

Aquí está el esqueleto, y el orden no es arbitrario. Igual que en el manejo de errores primero se diagnostica y después se configura, aquí primero se mide y después se optimiza —y las optimizaciones van de la de mayor impacto a la de menor—.

┌─────────────────────────────────────────────────────────────┐
│  L2  MEDIR    ¿dónde se va el tiempo? (las tres cubetas)     │
│         │                                                    │
│         ▼                                                    │
│  L3  LOTES    procesar por partes en vez de todo de golpe    │
│  L4  MEMORIA  no arrastrar lo que no usas (binarios)         │
│  L5  LLAMADAS ◄── la de MAYOR impacto: 300 llamadas → pocas  │
│  L6  RITMO    concurrencia y límites de tasa (la paradoja)   │
│         │                                                    │
│         ▼                                                    │
│  L7  FRONTERA cuando ya no es el workflow: cruzar a infra    │
│  L8  PROYECTO inventory-update: 11 min → segundos, con prueba│
└─────────────────────────────────────────────────────────────┘

Lección 2 — Dónde se va el tiempo de verdad. Antes de tocar nada, medir. Cómo leer los tiempos por nodo en una ejecución, y la trampa que engaña a todo el mundo: el nodo que aparece lento muchas veces solo está esperando a otro. Distinguir las tres cubetas —cómputo, espera de red, cola— porque cada una se arregla distinto. La regla de oro del módulo vive aquí: optimizar sin medir es adivinar.

Lección 3 — Procesar por lotes sin morir en el intento. Qué pasa cuando entran diez mil items de golpe, y cómo procesarlos por partes con el nodo Loop Over Items. El tamaño del lote es una decisión con dos costos opuestos que tira de lados contrarios: lotes chicos = muchos viajes; lotes grandes = mucha memoria y mucho que rehacer si uno falla. No hay número mágico; hay un método para encontrar el tuyo.

Lección 4 — Memoria y cargas grandes. Por qué un workflow se queda sin memoria y qué se lleva por delante cuando pasa. El costo silencioso de arrastrar campos que no vas a usar, y el caso más caro de todos: los datos binarios —PDFs, imágenes—, por qué pesan tanto y cómo se sueltan a tiempo.

Lección 5 — Reducir llamadas externas. La optimización de mayor impacto y la que menos se aplica. Una llamada por item contra una llamada por lote. Cómo detectar el patrón, cuándo la API ofrece una operación masiva y qué hacer cuando no. Aquí inventory-update baja de once minutos a segundos: es el clímax.

Lección 6 — Concurrencia y límites de tasa. Cuántas cosas a la vez sin que el otro sistema te bloquee. Qué es un límite de tasa y cómo leer la respuesta que te lo anuncia. Y la paradoja que arruina a mucha gente: subir la concurrencia puede hacer el workflow más lento, porque el otro lado empieza a rechazarte y todo se reintenta.

Lección 7 — Cuando el workflow no es el problema. La frontera. Las señales medibles de que ya optimizaste lo optimizable y el cuello está en la instancia. Qué evidencia reunir antes de gastar en infraestructura, y el cruce explícito a la guía que sí monta el modo cola.

Lección 8 — Proyecto: hacer rápido un workflow lento. Tomar inventory-update con sus once minutos, medirlo, aplicar las técnicas en orden de impacto, y entregar la comparación antes/después con la evidencia. Incluye el veredicto honesto: hasta dónde llegó la optimización y si hace falta cruzar a infraestructura.

La frontera con la guía de self-hosting (léela ahora, no al final)

Esto conviene decirlo temprano y con nombre propio, porque hay otra guía en el ecosistema que se llama parecido y que hace lo contrario que esta, y no quiero que las confundas.

La guía Self-Hosting y Operaciones de n8n (n8n-self-hosting-and-operations-guide), en su Módulo 6, monta el modo cola (queue mode): agrega Redis como intermediario, corre contenedores worker que ejecutan el trabajo pesado en paralelo, pone límites de recursos y health checks. Es escalar la instancia: darle a n8n más manos para trabajar.

Este módulo hace lo otro. No monta nada de eso. Aquí no vas a ver Redis, ni workers, ni un docker-compose.yml, ni una sola variable de escalado de la instancia. Aquí se trabaja sobre el workflow: por qué va lento y cómo se arregla sin tocar la infraestructura. La diferencia se resume en una frase:

Esta guía hace que cada workflow pida menos. Aquella hace que la instancia aguante más.

Y son dos cosas que se hacen en orden, no a la vez. Primero se optimiza el workflow —es más barato, más rápido y muchas veces suficiente—. Solo cuando eso ya no alcanza se escala la instancia. Comprar workers para un workflow que hace trescientas llamadas de a una es pagar para hacer más rápido algo que no deberías estar haciendo. Primero deja de hacer las trescientas llamadas; después, si de verdad el volumen agregado de todos tus workflows satura la instancia, escalas.

Pregunta	Dónde vive
¿Por qué mi workflow tarda 11 minutos y cómo lo bajo a segundos?	Aquí
¿Cómo hago menos llamadas a una API?	Aquí, lección 5
¿Cómo proceso 10.000 items sin quedarme sin memoria?	Aquí, lecciones 3 y 4
¿Cómo monto Redis y workers para correr más ejecuciones a la vez?	Self-hosting, Módulo 6
¿Cómo pongo límites de CPU y RAM a la instancia?	Self-hosting, Módulo 6
¿Cómo sé que ya optimicé todo y de verdad me toca escalar?	Aquí, lección 7 → y de ahí cruzas

La lección 7 es la bisagra entre las dos guías. Es contenido, no una nota al pie: enseña a reconocer con evidencia el punto exacto en que la optimización del workflow ya dio todo lo que podía dar y el cuello pasó a estar en la instancia —cuando la cubeta de cola es la que domina—. En ese punto, y solo ahí, te manda a la otra guía a montar el modo cola.

Qué vas a poder hacer al terminar el módulo

Al final de la lección 8 vas a poder:

• Medir dónde se va el tiempo de un workflow leyendo los tiempos por nodo, y clasificar ese tiempo en cómputo, espera de red o cola.
• No caer en la trampa de optimizar el nodo que solo parece lento porque está esperando a otro.
• Procesar por lotes con Loop Over Items, y elegir el tamaño del lote entendiendo sus dos costos opuestos.
• Reducir el consumo de memoria soltando campos y binarios que no usas, y saber por qué los binarios son el caso más caro.
• Convertir muchas llamadas en pocas, detectando el patrón "una llamada por item" y rediseñando el flujo para llamar por lote.
• Encontrar el punto de concurrencia que va rápido sin tumbar al erp, y leer un límite de tasa cuando la API te lo anuncia.
• Distinguir con evidencia cuándo el problema es el workflow (y lo arreglas aquí) y cuándo es la instancia (y cruzas a self-hosting).

Lo que no vas a hacer aquí, y está bien: montar el modo cola, configurar workers, poner límites de recursos a la instancia o instrumentar métricas y percentiles para un dashboard. Lo primero es la guía de self-hosting; lo de las métricas es el Módulo 4 de esta misma guía, que las mide desde el ángulo de qué se observa en general. Aquí usamos la medición con un solo fin: optimizar.

Errores comunes

Comprar servidor sin haber medido (conceptual). Qué pasa: un workflow se pone lento, alguien concluye "n8n se quedó corto" y sube el VPS o pide un plan más caro. El workflow sigue igual de lento, porque su cuello era espera de red y ningún procesador acelera una espera. Por qué pasa: la lentitud dispara el reflejo de "más potencia", y ese reflejo es correcto para computadoras que calculan mucho, no para las que esperan mucho —que son casi todas las de integración—. Cómo detectarlo: si vas a gastar en infraestructura y no tienes una ejecución medida que muestre en qué nodo se va el tiempo, estás por comprar a ciegas. Cómo corregirlo: mide primero (lección 2). Si el tiempo se va en espera de red, ningún servidor lo arregla; si se va en cola, entonces sí es infraestructura, y la lección 7 te lo confirma con evidencia.

Optimizar el nodo que parece lento en vez del que causa la lentitud (conceptual). Qué pasa: se mira la ejecución, un nodo aparece con un tiempo enorme, y se invierte el esfuerzo en hacerlo "más eficiente" —reescribir su código, simplificar su lógica— sin resultado. Por qué pasa: en n8n el tiempo de un nodo incluye lo que ese nodo pasó esperando la respuesta de un sistema externo; un nodo HTTP Request que tarda diez minutos no está trabajando diez minutos, está esperando diez minutos. Optimizar su configuración no toca la espera. Cómo detectarlo: pregúntate si el nodo lento calcula o espera. Un nodo Code que recorre datos calcula; un HTTP Request, un Postgres o un nodo de servicio esperan. Cómo corregirlo: si espera, la palanca no es hacerlo más rápido, es hacerlo menos veces (lección 5) o hacerlo esperar a algo más rápido, que casi nunca controlas. La lección 2 desarma esta trampa en detalle.

Confundir "escalar la instancia" con "optimizar el workflow" (conceptual). Qué pasa: alguien lee sobre el modo cola, monta Redis y workers, y espera que su workflow lento se vuelva rápido. No se vuelve: el modo cola reparte muchas ejecuciones entre varias manos, pero una sola ejecución sigue tardando exactamente lo mismo. inventory-update con sus once minutos seguiría tardando once minutos en modo cola, porque el problema no era cuántas ejecuciones caben a la vez, era qué hace por dentro cada una. Por qué pasa: las dos cosas suenan a "hacer n8n más rápido" y se mezclan. Cómo detectarlo: pregúntate si tu problema es "una ejecución tarda demasiado" (workflow, aquí) o "muchas ejecuciones se encolan y esperan turno" (instancia, self-hosting). Cómo corregirlo: primero optimiza el workflow; el modo cola no acelera una ejecución individual, y montarlo antes de tiempo es resolver un problema que todavía no tienes.

Ejercicios

Ejercicio 1 — Clasifica el tiempo en cubetas. Para cada una de estas situaciones de Terra Market, di en cuál de las tres cubetas —cómputo, espera de red, cola— se está yendo el tiempo, y si comprar un servidor más grande ayudaría.

(a) inventory-update hace 300 llamadas al erp, una por sku, y cada una tarda 2 segundos en responder. (b) Un workflow recorre una lista de 50.000 registros en un nodo Code para reordenarlos por fecha, y ese nodo tarda 8 segundos. (c) A las 21:00, hora pico, hay tantas ejecuciones de order-sync disparándose que algunas tardan un minuto en empezar porque están formadas esperando turno.

Ver solución

(a) Espera de red. Los 600 segundos son n8n parado esperando al erp. Un servidor más grande no ayuda en nada: la espera no la acelera el procesador. La solución es hacer menos llamadas (lección 5).

(b) Cómputo. Aquí n8n sí está trabajando: recorre cincuenta mil elementos y los ordena. Esta es la única de las tres donde un procesador más rápido ayudaría algo. Pero fíjate en la escala: son 8 segundos, no 11 minutos. La cubeta de cómputo casi siempre es la pequeña. Antes de comprar máquina por 8 segundos, verifica que no haya algo más caro escondido.

(c) Cola. Las ejecuciones no tardan más en correr; tardan en empezar, porque la instancia está saturada de trabajo simultáneo. Esta es la única de las tres que es un problema real de infraestructura, y es exactamente la señal de la lección 7. Aquí sí podría tener sentido escalar la instancia —pero solo después de confirmar que cada ejecución ya está optimizada—.

Por qué funciona: las tres cubetas piden respuestas distintas. Confundirlas es lo que lleva a gastar en el lugar equivocado. La (a) se arregla en este módulo, la (b) probablemente ni valga la pena tocarla, y la (c) es la que cruza a la otra guía.

Ejercicio 2 — El reflejo caro. El jefe de tecnología de Terra Market ve que inventory-update tarda 11 minutos y dice: "aprobemos el VPS más grande, es urgente porque se va a solapar consigo mismo". Tú sospechas que es dinero tirado. Escribe, en tres frases, (a) qué le pedirías ver antes de aprobar el gasto, (b) qué esperas encontrar, y (c) qué le dirías si tu sospecha se confirma.

Ver solución

(a) Le pediría abrir una ejecución de inventory-update en la lista de ejecuciones y mirar el tiempo de cada nodo, para ver dónde se van los once minutos antes de gastar un peso.

(b) Espero encontrar que casi todo el tiempo se concentra en un nodo HTTP Request que llama al erp una vez por sku —trescientas llamadas—, y que ese tiempo es espera de red, no cómputo de n8n.

(c) Le diría: "el servidor no va a cambiar nada, porque durante esos once minutos n8n no está ocupado, está esperando al erp trescientas veces. Si en vez de trescientas llamadas hacemos unas pocas por lote, baja a segundos sin gastar en máquina. Dame una tarde antes de aprobar el VPS."

Por qué funciona: la respuesta correcta nunca es "no escales, punto". Es "no escales a ciegas". A veces escalar es lo correcto —la situación (c) del ejercicio anterior—, pero eso se decide con la ejecución medida enfrente, no con el reflejo. La lección 7 te enseña a distinguir cuál de los dos casos tienes.

Ejercicio 3 — Ordena el ataque. Un compañero te dice que su workflow lento hace tres cosas ineficientes: (i) llama a una API una vez por item cuando podría llamar por lote, (ii) arrastra un campo raw_html gigante que nunca usa, y (iii) procesa todo de golpe en vez de por lotes. Solo tienes tiempo de arreglar una hoy. ¿Cuál atacas primero y por qué? ¿Qué necesitas antes de decidirlo?

Ver solución

Lo primero, antes de elegir, es medir: abrir una ejecución y ver dónde se va el tiempo de verdad. Sin eso, cualquier orden es una corazonada. Pero si la medición confirma lo esperable, el orden de ataque es:

1. (i) Las llamadas por item. Es, casi siempre, la de mayor impacto por lejos —es la lección 5 y la razón de que sea el clímax del módulo—. Convertir "una llamada por item" en "una por lote" suele colapsar el tiempo de minutos a segundos.
2. (iii) Procesar por lotes. Ayuda con memoria y con resiliencia, pero rara vez es el mayor ahorro de tiempo si el cuello era la red.
3. (ii) El campo raw_html. Importa para memoria (lección 4), y puede ser la diferencia entre que el workflow termine o se caiga si el campo es enorme. Pero si el workflow termina y solo va lento, este suele mover menos la aguja de tiempo que reducir llamadas.

Por qué funciona: el criterio no es "arregla todo", es "arregla en orden de impacto, y el impacto lo dice la medición". El instinto de arreglar lo que es fácil o lo que salta a la vista te puede tener toda una tarde puliendo (ii) mientras (i) seguía costando diez minutos por corrida. Este orden —medir, luego atacar de mayor a menor impacto— es el esqueleto exacto del proyecto de la lección 8.

Resumen y siguiente paso

En esta lección viste la tesis de todo el módulo con la imagen de las dos personas frente al mismo semáforo: una compra un carro nuevo y sigue igual de atascada; la otra mide, encuentra el tramo de dos cuadras y lo esquiva en el mismo carro viejo. Conociste el caso que va a guiar el módulo: inventory-update, que pasó de 40 segundos a 11 minutos con los mismos 300 sku, no porque n8n se quedara chico, sino porque el erp se puso lento y dejó a la vista un workflow que siempre hizo trescientas llamadas de a una. Viste las tres cubetas donde se va el tiempo —cómputo, espera de red y cola— y que solo la primera se arregla con más máquina, mientras que la lentitud real casi siempre vive en la segunda. Reencontraste a Terra Market y sus tres protagonistas, y recibiste el mapa: medir (L2), después optimizar de mayor a menor impacto (L3 a L6), después reconocer la frontera con la infraestructura (L7), y demostrarlo todo sobre inventory-update (L8). Y quedó marcada, con nombre propio, la frontera con la guía de self-hosting: esta hace que cada workflow pida menos, aquella hace que la instancia aguante más, y se hacen en ese orden.

Antes de avanzar deberías poder: explicar en una frase por qué "más máquina" casi nunca arregla un workflow lento; nombrar las tres cubetas de tiempo y decir cuál se arregla con infraestructura; y contar el caso de inventory-update —qué pasó, por qué, y hacia dónde va el arreglo—.

Lo que todavía no hiciste es lo primero de la lista: medir. Porque toda la sabiduría de este módulo se apoya en un dato que aún no tienes: en cuál nodo, exactamente, se va el tiempo de tu workflow. La lección 2 abre el panel de ejecuciones, te enseña a leer el tiempo de cada nodo, y —lo más importante— te muestra la trampa que engaña a casi todo el mundo: el nodo que aparece más lento muchas veces no es el culpable, solo es el que está esperando al culpable. Sin saber leer eso, cualquier optimización que hagas después es una apuesta.

Recursos

• Performance and benchmarking — n8n Docs — la página oficial sobre rendimiento de n8n, útil para entender qué factores lo afectan; complementa la idea de las tres cubetas de esta lección.
• View executions for a single workflow — n8n Docs — dónde vive la lista de ejecuciones que vas a abrir en la lección 2 para medir.
• Fix memory issues — n8n Docs — recomendaciones oficiales para reducir el consumo de memoria de un workflow, base de la lección 4.
• Configuring queue mode — n8n Docs — el modo cola, que este módulo no monta; queda aquí para que veas a qué se refiere la frontera de la lección 7, desarrollada en la guía de self-hosting.
• Release notes 2.x — n8n Docs — el historial de la versión 2 (publicada el 5 de diciembre de 2025), útil para confirmar contra qué versión estás leyendo esta guía.