5. Reducir llamadas externas

Descripción

Al terminar esta lección vas a poder detectar el patrón más caro y más común de los workflows de integración —hacer una llamada externa por cada item cuando podrías hacer una por lote—, y vas a poder rediseñar el flujo para eliminarlo. Vas a saber cómo averiguar si una API ofrece una operación masiva, qué hacer cuando no la ofrece, y cómo guardar en memoria lo que se repite dentro de una misma ejecución para no pedirlo dos veces. Y vas a ver a inventory-update bajar de once minutos a segundos, que es el clímax de todo el módulo.

Esto importa porque, de todas las técnicas de rendimiento, esta es la de mayor impacto por lejos —y la que menos gente aplica—. La lección 2 casi siempre te va a mostrar que el tiempo de un workflow lento se va en espera de red, repetida muchas veces. Reducir esas muchas veces a unas pocas no te ahorra un 10% ni un 30%: te ahorra órdenes de magnitud. Es la diferencia entre once minutos y trece segundos. Y es la que menos se aplica por una razón simple: el patrón "una llamada por item" es lo natural de construir —lo obvio, lo que sale primero— y funciona perfecto en las pruebas con cinco items. Su costo solo aparece con volumen y con una API lenta, que es justo cuando ya está en producción y nadie quiere tocarlo.

Conexión con el módulo: esta es la lección hacia la que apuntaba todo. La 2 te enseñó a encontrar el cuello; en la enorme mayoría de los workflows de integración, ese cuello es este. La 3 te dio los lotes, que son la herramienta que vas a usar aquí para agrupar. La 4 te dio la conciencia de la memoria, que vas a necesitar para no pasarte al agrupar. Y hay una restricción de n8n 2.0 que define cómo se resuelve esto y que quiero que tengas presente desde ya: el nodo Code no puede hacer llamadas HTTP. Así que "reducir llamadas" no se resuelve escribiendo un bucle con peticiones dentro del código —eso es imposible en n8n 2.0—; se resuelve rediseñando el flujo de nodos. Esa es la parte técnica central de la lección.

Ir al súper una vez con lista, no cien veces por cada cosa

Imagina que tienes que comprar cien cosas del supermercado. Hay dos formas.

La forma de una llamada por item: sales de tu casa, manejas al súper, compras una cosa, manejas de vuelta a casa, la guardas. Y repites. Cien veces. Cien viajes de ida y vuelta para cien productos. Es evidentemente absurdo —nadie compra así—, pero fíjate en que la parte cara no es meter el producto en el carrito; eso toma segundos. La parte cara es el viaje: salir, manejar, estacionar, volver. Repetido cien veces, el viaje se come el día entero, aunque las compras en sí sumen diez minutos.

La forma de una llamada por lote: haces una lista, manejas al súper una vez, metes las cien cosas al carrito, y vuelves. Un viaje. Las compras dentro del súper toman un poco más que comprar una sola cosa —tienes que recorrer más pasillos—, pero te ahorras noventa y nueve viajes. El total se desploma, no porque comprar sea más rápido, sino porque dejaste de viajar cien veces.

Un workflow que llama a una API una vez por item está haciendo la primera forma: por cada sku, un viaje completo de ida y vuelta al erp —abrir la conexión, mandar, esperar, recibir, cerrar—. El "producto" (el dato que pide) es chiquito; el "viaje" (la ida y vuelta por la red, más el tiempo que el erp tarda en atender) es lo caro. Y como en el súper, la solución no es viajar más rápido —no controlas la velocidad de la carretera ni la del erp—; es viajar menos veces, llevando una lista.

Esa es toda la lección en una imagen: cambia cien viajes de una cosa por un viaje de cien cosas. Lo difícil no es la idea, es reconocer cuándo tu workflow está viajando de más, y saber rediseñarlo para que lleve lista.

Cómo se ve el patrón "una llamada por item" en n8n

Antes de arreglarlo, hay que reconocerlo. El patrón tiene una forma visual muy característica en el lienzo: un nodo que llama a un sistema externo, colocado dentro de un bucle (o alimentado por muchos items que lo hacen correr una vez por cada uno).

    El patrón caro:

    300 sku ──► Loop Over Items ──► HTTP: GET /inventory/{{sku}}
                     ▲                        │
                     └────────────────────────┘
                        una llamada por cada sku
                        = 300 viajes al ERP

Cada vuelta del bucle dispara una petición al erp, para un sku. Trescientos sku, trescientas peticiones, trescientos viajes. En el panel de la lección 2, esto se ve como un nodo HTTP Request con un tiempo enorme, dentro de un Loop Over Items, y el tiempo es proporcional al número de items. Esa proporcionalidad —"si duplico los items, se duplica el tiempo"— es la firma del patrón.

La pregunta que lo delata, y que deberías hacerte de cada nodo que llama afuera:

¿Este nodo llama al sistema externo una vez por item, o una vez por lote? Si es una vez por item, y hay muchos items, ahí está tu cuello.

Ahora, el arreglo. Y aquí es donde la restricción de n8n 2.0 manda. En otros entornos de programación, la tentación sería escribir un poco de código que, dentro de un bucle, junte los sku y haga una llamada. Pero el nodo Code de n8n 2.0 no puede hacer llamadas HTTP —ni con fetch, ni con axios, ni con this.helpers—. El código no viaja. Entonces el rediseño se hace con nodos, en tres movimientos:

1. Agrupar los items en uno (o pocos) que contengan la lista de sku. Esto se hace con un nodo Code o con el nodo Aggregate.
2. Una sola llamada HTTP Request que manda esa lista y pide el stock de todos de golpe, usando la operación masiva del erp.
3. Desagrupar la respuesta —que viene con el stock de todos— de vuelta en items individuales, con un nodo Code o con el nodo Split Out.

El Code sí participa —en agrupar y desagrupar, que son puro trabajo sobre datos que ya tienes en memoria, sin red—. Lo que el Code no hace es la llamada; esa la hace el nodo HTTP Request, una sola vez, con el lote entero. Es la división del trabajo que impone n8n 2.0, y resulta ser también la más limpia: cada nodo hace lo suyo.

    El arreglo (agrupar → una llamada → desagrupar):

    300 sku ──► Code/Aggregate: ──► HTTP: POST /inventory/batch ──► Code/Split Out:
                juntar los 300         (una llamada con los           volver a
                sku en una lista        300 sku en el body)           300 items
                     ▲                        ▲                            │
                un solo item          UN viaje al ERP              300 items con
                con [300 sku]         (o pocos, ver abajo)         su stock

Averiguar si la API ofrece una operación masiva

El arreglo de arriba depende de una condición: que el erp acepte que le pidas varios sku de una vez. No todas las APIs lo permiten, así que el primer paso real es averiguarlo. Aquí va cómo, en orden.

Busca en la documentación de la API un endpoint "batch", "bulk" o de lista. Las señales típicas: un endpoint que en vez de GET /inventory/{sku} (uno) ofrece POST /inventory/batch con una lista en el cuerpo, o un GET /inventory?skus=A,B,C que acepta varios separados por coma, o un endpoint de "búsqueda" que devuelve muchos registros con un filtro. Los verbos y palabras a buscar: batch, bulk, multi, list, search, query.

Mira si el endpoint que ya usas acepta más de uno. A veces el mismo endpoint que llamas de a uno acepta una lista sin que lo hayas notado —el campo que le mandas como un valor único también admite un arreglo—. Vale la pena leer bien su especificación antes de asumir que solo toma uno.

Fíjate en los límites de la operación masiva. Casi ninguna API te deja pedir "todos los que quieras" en una llamada. Lo normal es un tope: "hasta 100 por petición", "máximo 1 MB de cuerpo". Ese tope define tu tamaño de lote. Si el erp acepta hasta 100 sku por llamada y tienes 300, no haces una llamada: haces tres de 100. Que no es una, pero es tres en vez de trescientas —el 99% del ahorro, con un límite respetado—.

Aquí es donde los lotes de la lección 3 y esta lección se dan la mano. El Loop Over Items con Batch Size: 100 no desaparece: se convierte en el mecanismo que respeta el tope de la API. Agrupas de a 100 (el máximo del erp), haces una llamada por grupo, desagrupas. Trescientos sku → tres grupos de 100 → tres llamadas. El bucle sigue ahí, pero ahora da tres vueltas en vez de trescientas, y cada vuelta lleva una lista, no un solo item.

Ejemplo trabajado: inventory-update baja de 11 minutos a 13 segundos

Este es el momento del módulo. Vamos a arreglar el workflow que abrió todo.

El diagnóstico (de la lección 2). inventory-update tarda 11 minutos. El recibo mostró que 630 de esos segundos se van en HTTP: GET stock, dentro de un Loop Over Items, que llama al erp una vez por cada uno de los 300 sku. Cada llamada tarda ~2 segundos porque el catálogo del erp creció. 300 × 2 s = 600 s. Ahí está el patrón caro, con nombre y número.

El paso de averiguación. Revisas la documentación del erp y encuentras que sí ofrece una operación masiva: POST /inventory/batch, que acepta una lista de hasta 100 sku en el cuerpo y devuelve el stock de todos. Tope: 100 por llamada.

El rediseño. El workflow pasa de esto:

ANTES (300 viajes):
Schedule ─► ERP: get sku list ─► Loop Over Items ─► HTTP: GET /inventory/{{sku}} ─┐
                                       ▲                                          │
                                       └──────────────────────────────────────────┘
                                       300 vueltas, 300 llamadas · ~630 s

a esto:

DESPUÉS (3 viajes):
Schedule ─► ERP: get sku list ─► Loop Over Items ─► Code: juntar los 100     ─┐
                                 (Batch Size: 100)    sku de esta tanda        │
                                       ▲              en una lista             │
                                       │                    │                  │
                                       │                    ▼                  │
                                       │            HTTP: POST /inventory/batch │
                                       │            (los 100 de la tanda)       │
                                       │                    │                  │
                                       │            Code: desagrupar la         │
                                       │            respuesta en 100 items      │
                                       │                    │                  │
                                       └────────────────────┘  de vuelta al Loop
                                       3 vueltas, 3 llamadas · ~8 s

Tres tandas de 100. Cada tanda: agrupar los 100 sku en una lista (Code, sin red), una llamada POST /inventory/batch con esos 100 (HTTP, el único viaje), desagrupar la respuesta en 100 items con su stock (Code, sin red), y de vuelta al bucle por la siguiente tanda.

El nuevo recibo:

Schedule Trigger ........... 0.0 s
ERP: get sku list .......... 1.5 s
Loop (×3):
  Code: agrupar ............ ~0.1 s por tanda
  HTTP: POST batch ......... ~2.5 s por tanda   ◄── 3 viajes, no 300
  Code: desagrupar ......... ~0.3 s por tanda
Code: transform stock ...... 3.0 s
Push to storefront (bulk) .. 2.0 s   ◄── (ver abajo)
Postgres: log .............. 0.5 s
                            ─────────
Total ...................... ~13 s

De 664 segundos a ~13. Cincuenta veces más rápido. Y más rápido incluso que los 40 segundos originales, porque de paso arreglamos el segundo cuello: la escritura a storefront, que también era una por sku, ahora es una sola llamada masiva.

Qué esperar. No esperes que cada workflow baje exactamente cincuenta veces —el factor depende de cuántas llamadas eliminas y de cuánto tardaba cada una—. Lo que sí puedes esperar es el orden del cambio: cuando el cuello era "N llamadas de a una" y lo conviertes en "unas pocas de a lote", no ganas un porcentaje, ganas un orden de magnitud. Un servidor más grande le habría ahorrado a Terra Market, con suerte, un 10%, y le habría costado dinero cada mes. Este rediseño le ahorró el 98%, no le cuesta nada al mes, y no tocó el servidor. Esa comparación es, en una línea, la tesis del módulo entero demostrada con números.

Qué hacer cuando la API NO ofrece operación masiva

No siempre hay suerte. A veces el erp —o el servicio que sea— solo ofrece el endpoint de a uno, sin batch, sin lista. No estás sin opciones; están en orden de preferencia.

Opción 1 — Vuelve a preguntar si de verdad necesitas todas las llamadas. Antes de aceptar N llamadas, cuestiona el N. ¿Necesitas consultar los 300 sku, o solo los que cambiaron desde la última corrida? Muchas veces el patrón caro esconde un desperdicio de raíz: se consulta todo cada vez cuando bastaría consultar lo que cambió. Reducir de 300 a 12 llamadas "de a una" puede ser mejor que optimizar el mecanismo de las 300. La llamada más barata es la que no haces.

Opción 2 — Memoiza lo que se repite (la próxima sección). Si dentro de una misma corrida llamas varias veces por lo mismo, guárdalo la primera vez y reúsalo. Esto elimina las llamadas repetidas, aunque no las únicas.

Opción 3 — Si de verdad tienes que hacer N llamadas de a una, controla el ritmo. Cuando no hay forma de agrupar y cada llamada es necesaria y distinta, el problema ya no es cuántas llamadas sino cómo las haces sin que el sistema externo te bloquee. Eso es concurrencia y límites de tasa, y es toda la lección 6. No es tan bueno como agrupar —sigues haciendo N viajes—, pero al menos los haces al ritmo correcto.

El orden importa: primero intenta hacer menos llamadas (agrupar, o consultar solo lo que cambió), y solo si es imposible, ocúpate de hacer bien las que quedan. Mucha gente salta directo a la opción 3 —afinar la concurrencia de las trescientas llamadas— cuando la opción 1 o 2 las habría reducido a treinta.

Un detalle útil para cuando te quedas con la opción 3: el propio nodo HTTP Request trae, dentro de sus opciones, un apartado de Batching con dos parámetros —Items per Batch (cuántos items agrupa por tanda de peticiones) y Batch Interval (cuánto espera entre tanda y tanda, en milisegundos)—. Ojo con no confundirlo con el rediseño de esta lección: Batching no convierte N llamadas en una sola llamada masiva —no arma un cuerpo con la lista—; lo que hace es espaciar las N llamadas para no dispararlas todas de golpe. Es una herramienta de ritmo, no de reducción. Sirve justo para la opción 3, cuando la API no ofrece batch de verdad y tienes que hacer las N llamadas igual, pero quieres hacerlas a un paso que el otro lado tolere. Volveremos a él en la lección 6, que es sobre exactamente eso: el ritmo.

Memoizar: no pidas dos veces lo mismo en la misma corrida

Hay una variante del desperdicio que merece su propia sección, porque es sutil y muy común: pedir la misma cosa varias veces dentro de una sola ejecución.

El nombre técnico es memoizar: recordar el resultado de una llamada para no repetirla. La imagen cotidiana: si estás cocinando y la receta te pide sal en tres pasos, no vas tres veces a la despensa por la sal —la traes una vez y la dejas a mano en la mesa—. Ir tres veces a la despensa por lo mismo es exactamente lo que hace un workflow que llama al erp por el mismo dato una y otra vez.

Un ejemplo de Terra Market. Supón que inventory-update, además del stock, necesita el nombre del proveedor de cada sku, y lo obtiene con GET /supplier/{supplier_id}. Pero muchos sku comparten proveedor: los 300 sku vienen de solo 20 proveedores. Un workflow ingenuo llama a /supplier/ 300 veces —una por sku—, cuando solo hay 20 proveedores distintos. Está yendo a la despensa 300 veces por una sal que solo tiene 20 sabores.

La memoización, con nodos, se ve así: en un nodo Code (que trabaja sobre datos en memoria, sin red), llevas un objeto que hace de "mesa de la cocina" donde guardas los proveedores que ya viste. Antes de necesitar un proveedor, miras si ya está en la mesa; si sí, lo usas; si no... y aquí está la restricción de n8n 2.0 otra vez: el Code no puede hacer la llamada. Así que el patrón real es primero quedarte con la lista de supplier_id únicos (un Code que deduplica: de 300 baja a 20), y después llamar al erp solo por esos 20 —idealmente con la operación masiva si existe—. El Code no llama; el Code reduce la lista de lo que hay que llamar, y el nodo HTTP llama por esa lista corta.

    Sin memoizar:  300 sku ──► HTTP /supplier/{id} ×300   (300 llamadas)

    Con dedup:     300 sku ──► Code: sacar los 20         ──► HTTP /supplier ×20
                               supplier_id únicos              (o 1 batch de 20)

La idea general: dentro de una misma ejecución, calcula el conjunto de cosas distintas que necesitas antes de llamar, y llama solo por ellas. Trescientas llamadas por veinte proveedores distintos es tirar el 93% de los viajes.

Una frontera honesta. Esto memoiza dentro de una ejecución. Recordar cosas entre ejecuciones distintas —un caché que sobreviva de la corrida de las 14:15 a la de las 14:30— es otra cosa, más compleja, que necesita guardar el dato en algún lado (una base de datos, un almacén de datos estáticos) y decidir cuándo expira. Eso toca diseño de datos y no es de este módulo. Aquí nos quedamos con lo de mayor impacto y menor riesgo: no repetir dentro de la misma corrida.

Errores comunes

No reconocer el patrón porque "así funcionó siempre" (conceptual). Qué pasa: el workflow llama de a uno desde el día que se construyó, nunca dio problema, y cuando se pone lento nadie sospecha del patrón porque "siempre estuvo así". Por qué pasa: "una llamada por item" es lo natural de construir y funciona perfecto con pocos items; su costo estaba escondido detrás de una API rápida y salió a la luz cuando la API se puso lenta o el volumen creció. Cómo detectarlo: busca en tus workflows nodos que llaman afuera dentro de un bucle, o alimentados por muchos items. Pregúntate: "¿esto llama una vez por item?". Si sí y hay volumen, es candidato. Cómo corregirlo: agrupar → una llamada → desagrupar, si la API lo permite. El que "siempre funcionó así" es justo el que más ahorro esconde.

Intentar hacer la llamada dentro del nodo Code (práctico). Qué pasa: alguien, con la idea correcta de "junto los items y hago una llamada", escribe un Code que intenta hacer la petición HTTP dentro del código —con fetch, axios o this.helpers— y n8n 2.0 lo rechaza. Por qué pasa: viene de otros entornos donde el código sí hace red, y no tiene presente que el Code de n8n 2.0 está aislado: sin HTTP, sin sistema de archivos. Cómo detectarlo: si tu plan para reducir llamadas incluye "y en el Code hago la petición", se va a estrellar. Cómo corregirlo: el Code agrupa y desagrupa (trabajo sobre datos); la llamada la hace el nodo HTTP Request, una vez, con el lote. Esa división no es un capricho, es la arquitectura de n8n 2.0, y de paso deja el workflow más claro.

Agrupar sin respetar el tope de la API (práctico). Qué pasa: se junta todo en una sola llamada —los 300, los 5.000— y la API responde con un error de "cuerpo demasiado grande" o "máximo 100 por petición". Por qué pasa: se entiende "una llamada por lote" como "una sola llamada para todo", ignorando que casi toda API masiva tiene un tope. Cómo detectarlo: si tu llamada masiva falla con volúmenes grandes pero funciona con pocos, chocaste con el tope. Cómo corregirlo: lee el límite en la documentación (100, 500, 1 MB…) y usa Loop Over Items con ese Batch Size para hacer varias llamadas que lo respeten. El objetivo no es una llamada; es pocas, dentro del límite.

Saltar a afinar la concurrencia sin intentar reducir primero (conceptual). Qué pasa: frente a 300 llamadas lentas, alguien va directo a "las hago en paralelo para que terminen antes" —lección 6— sin preguntarse si podían ser 3 en vez de 300. Por qué pasa: la concurrencia suena a la solución técnica sofisticada, y reducir suena obvio, así que se subestima. Cómo detectarlo: si estás configurando cuántas llamadas paralelas hacer y no verificaste antes si la API ofrece batch o si consultas de más, te saltaste el paso de mayor impacto. Cómo corregirlo: primero reduce (agrupa, consulta solo lo que cambió, memoiza); después, para las llamadas que de verdad queden, ocúpate del ritmo. Paralelizar 300 llamadas innecesarias es hacer más rápido un desperdicio.

Consultar todo cada vez cuando bastaría lo que cambió (conceptual). Qué pasa: cada corrida vuelve a pedir el estado de los 300 sku, aunque entre una corrida y otra solo cambiaron 12. Por qué pasa: pedir todo es más simple de programar que llevar la cuenta de qué cambió. Cómo detectarlo: pregúntate si de verdad necesitas todos los datos cada vez, o solo los que se movieron desde la última corrida. Cómo corregirlo: si la API permite filtrar por "modificados desde tal fecha", úsalo; consultar 12 en vez de 300 es el mayor ahorro posible, porque la llamada más barata es la que no haces. No siempre se puede, pero vale la pena preguntarlo antes de optimizar las 300.

Ejercicios

Ejercicio 1 — Detecta y cuenta. Para cada workflow, di si tiene el patrón "una llamada por item", cuántas llamadas hace hoy, y cuántas haría bien rediseñado (asume que la API acepta operación masiva de hasta 50 por llamada).

(a) Un workflow recibe 200 pedidos y, por cada uno, llama a GET /customer/{id} para traer los datos del cliente. (b) Un workflow recibe 1.000 productos y hace una sola llamada POST /products/import con los 1.000 en el cuerpo. (c) Un workflow recibe 200 pedidos que pertenecen a 30 clientes distintos y llama a GET /customer/{id} por cada pedido.

Ver solución

(a) Sí tiene el patrón. Hoy hace 200 llamadas (una por pedido). Rediseñado con batch de 50: junta los 200 customer_id, los pide de a 50 → 4 llamadas. De 200 a 4.

(b) No tiene el patrón. Ya hace 1 llamada con todos. Está bien —salvo que 1.000 supere el tope de 50, en cuyo caso el error de "demasiados" te obligaría a partir en 20 llamadas de 50—. Ojo con el tope: "una sola para todo" solo funciona si cabe.

(c) Sí tiene el patrón, y además desperdicio. Hoy hace 200 llamadas, pero solo hay 30 clientes distintos: 170 de esas llamadas piden un cliente que ya pidió. Rediseñado: dedup a 30 customer_id únicos (memoización), y de a 50 → 1 llamada (30 caben en una de 50). De 200 a 1. Este es el caso de mayor ahorro porque combina agrupar y no repetir.

Por qué funciona: contar las llamadas antes y después es la forma más directa de ver el impacto. Y el caso (c) muestra que a veces el patrón esconde dos desperdicios —muchas llamadas y llamadas repetidas—, y atacar los dos multiplica el ahorro.

Ejercicio 2 — El rediseño con nodos. Un workflow llama al erp una vez por cada uno de 400 sku para traer su precio. El erp ofrece POST /prices/batch con hasta 100 sku. Describe los nodos y el flujo del rediseño, y di explícitamente qué hace el Code y qué NO puede hacer.

Ver solución

El flujo:

1. Los 400 sku entran a un Loop Over Items con Batch Size: 100 → 4 tandas de 100.
2. Salida loop → un Code que agrupa los 100 sku de la tanda en una lista (un solo item con un arreglo de 100 sku). Esto es trabajo sobre datos en memoria: permitido.
3. → un HTTP Request que hace POST /prices/batch con esos 100 sku en el cuerpo. Esta es la única llamada de red, y la hace el nodo HTTP, no el Code.
4. → un Code (o un Split Out) que desagrupa la respuesta —los 100 precios— de vuelta en 100 items individuales.
5. La cadena vuelve al Loop Over Items por la siguiente tanda.
6. Cuando terminan las 4 tandas, la salida done sigue con lo que vaya después.

Resultado: 4 llamadas en vez de 400.

Qué hace el Code: agrupar (juntar los sku en una lista) y desagrupar (partir la respuesta en items). Qué no puede hacer el Code: la llamada al erp. En n8n 2.0 el Code no tiene HTTP; la petición es responsabilidad exclusiva del nodo HTTP Request. El Code prepara los datos para la llamada y ordena la respuesta; el HTTP viaja.

Por qué funciona: la restricción de n8n 2.0 —Code sin red— fuerza esta división de tres piezas, que resulta ser la más limpia: preparar, llamar, ordenar. Cada nodo hace una cosa, y la llamada queda visible en un nodo HTTP en vez de escondida en código.

Ejercicio 3 — La API sin batch. El carrier (andes-express) solo ofrece GET /tracking/{guide_id}, de a uno, sin operación masiva. Un workflow consulta el estado de 500 guías por corrida y tarda muchísimo. Ordena de mejor a peor las opciones que tienes, y explica por qué ese orden.

Ver solución

De mejor a peor:

1. Reducir el N: ¿necesito consultar las 500? Quizá solo las guías "en tránsito" cambian de estado; las "entregadas" ya no se mueven. Si de 500 solo 80 están activas, consulto 80. La mejor llamada es la que no hago. Esto es lo primero que intentaría.

2. Memoizar / deduplicar dentro de la corrida. Si por alguna razón la misma guía se consulta más de una vez en la corrida, dedup. (Menos probable aquí, porque cada guía es única, pero vale revisarlo.)

3. Controlar el ritmo de las que queden (lección 6). Si de verdad hay que consultar N guías distintas de a una porque no hay batch, entonces el problema pasa a ser hacerlas al ritmo que el carrier tolera sin bloquearte —concurrencia y límites de tasa—. No reduce el número de viajes, pero evita que el carrier te rechace y todo se reintente.

Por qué ese orden: primero se ataca cuántas llamadas (opciones 1 y 2, que las eliminan), y solo cuando no se pueden eliminar más, se ataca cómo hacer las que quedan (opción 3, que las gestiona). Saltar directo a la 3 —afinar la concurrencia de las 500— es optimizar el ritmo de viajes que quizá ni tenías que hacer. El carrier sin batch es frustrante, pero incluso ahí, reducir el N suele ganar más que cualquier truco de concurrencia.

Resumen y siguiente paso

En esta lección viste la optimización de mayor impacto del módulo con la imagen del supermercado: no hagas cien viajes de una cosa, haz un viaje de cien cosas, porque lo caro nunca fue meter el producto al carrito, fue el viaje. Aprendiste a reconocer el patrón "una llamada por item" —un nodo que llama afuera dentro de un bucle, con un tiempo proporcional al número de items— y a rediseñarlo en tres movimientos: agrupar (Code o Aggregate), una sola llamada por lote (HTTP Request), desagrupar (Code o Split Out). Y viste por qué en n8n 2.0 esto se hace con nodos y no con código: el nodo Code no puede hacer llamadas HTTP, así que agrupa y desagrupa, pero el viaje lo hace el nodo HTTP. Aprendiste a averiguar si una API ofrece operación masiva y a respetar su tope con el Loop Over Items de la lección 3; qué hacer cuando no la ofrece (reducir el N primero, después gestionar el ritmo); y a memoizar lo que se repite dentro de una corrida, deduplicando la lista de lo que hay que llamar antes de llamar. Y viste el clímax: inventory-update de once minutos a trece segundos —cincuenta veces— sin tocar el servidor, que es la tesis del módulo demostrada con números.

Antes de avanzar deberías poder: reconocer el patrón "una llamada por item" en un lienzo; describir el rediseño de tres nodos y decir por qué el Code no hace la llamada; y explicar por qué reducir llamadas gana órdenes de magnitud y no porcentajes.

Pero hay un caso que dejamos pendiente y que aparece cuando la API no ofrece batch: te quedan N llamadas distintas que sí tienes que hacer. La tentación entonces es hacerlas todas a la vez, en paralelo, para que terminen antes. La lección 6 es sobre por qué esa tentación tiene una trampa —subir la concurrencia puede hacer el workflow más lento, porque el otro lado empieza a rechazarte y todo se reintenta—, qué es un límite de tasa y cómo se lee la respuesta que te lo anuncia, y cómo encontrar el ritmo que va rápido sin tumbar al erp.

Recursos

• HTTP Request node — n8n Docs — el nodo que hace la llamada masiva; revisa sus opciones de cuerpo (body) para mandar una lista, y su Batching para espaciar varias llamadas.
• Aggregate node — n8n Docs — el nodo nativo para agrupar varios items en uno, alternativa al Code para el primer paso del rediseño.
• Split Out node — n8n Docs — el nodo nativo para desagrupar una lista de la respuesta en items individuales, alternativa al Code para el último paso.
• Loop Over Items (Split in Batches) — n8n Docs — el nodo que respeta el tope de la operación masiva, agrupando de a Batch Size.
• Code node — n8n Docs — la referencia del nodo Code, donde se confirma que en n8n no está pensado para hacer peticiones HTTP; su trabajo aquí es preparar y ordenar datos.