6. Concurrencia y límites de tasa

Descripción

Al terminar esta lección vas a poder decidir cuántas cosas hacer a la vez cuando un workflow tiene que hacer muchas llamadas que no se pueden agrupar, sin que el sistema del otro lado te bloquee. Vas a saber qué es un límite de tasa (rate limit) y cómo leer la respuesta con la que una API te avisa que te pasaste, y vas a entender la paradoja que arruina a mucha gente: subir la concurrencia puede hacer el workflow más lento, no más rápido, porque el otro lado empieza a rechazarte y todo se reintenta. Vas a terminar con un método para encontrar el ritmo que va rápido sin tumbar al erp.

Esto importa porque la concurrencia es la optimización que más traiciona a quien la aplica sin entenderla. Suena irresistible: "si hago las llamadas de a una tardo mucho; si las hago todas a la vez, terminan rápido". La intuición dice que más paralelo es más rápido, siempre. Y hasta cierto punto es verdad —pero pasado ese punto, la curva se invierte y empeora—, y el punto donde se invierte no lo pones tú, lo pone el sistema al que llamas. Pasarte de ese punto no es "un poco menos eficiente": es activar una reacción en cadena de rechazos y reintentos que puede dejar el workflow más lento que si hubieras ido de a uno, y de paso puede tumbarle el servicio a otros.

Conexión con el módulo: esta lección es la continuación natural de la 5. Ahí aprendiste que la mejor jugada es reducir llamadas —convertir trescientas en tres—. Pero la 5 terminó con un caso pendiente: cuando la API no ofrece operación masiva y te quedan N llamadas distintas que sí tienes que hacer. Esta lección es sobre ese caso: cómo hacer esas N llamadas al ritmo correcto. Es importante el orden mental: primero reduce (lección 5), después gestiona el ritmo (lección 6). La concurrencia es la palanca de las llamadas que no pudiste eliminar, no un sustituto de eliminarlas. Y una conexión con el Módulo 2: cuando el otro lado te rechaza, tus reintentos (la capa 1 del manejo de errores) entran en juego, y aquí vas a ver cómo esos reintentos, mal calibrados, pueden empeorar el problema en vez de arreglarlo.

La caseta de peaje con tres carriles

Imagina una caseta de peaje que puede atender tres carros a la vez —tiene tres carriles con casetero—. Detrás vienen cien carros.

Si mandas los carros de a uno —un carril, los otros dos vacíos—, la fila avanza, pero lento: desperdicias dos terceras partes de la capacidad de la caseta. Podrías estar atendiendo tres a la vez y solo atiendes uno.

Si mandas los carros de a tres —llenas los tres carriles—, la caseta trabaja a tope y la fila avanza lo más rápido posible. Ese es el punto óptimo: tantos carros en paralelo como carriles hay.

Ahora, ¿qué pasa si, creyendo que "más es más rápido", intentas meter diez carros a la vez en una caseta de tres carriles? No caben. Se amontonan en la entrada, se estorban, algunos tienen que retroceder y volver a intentar, se arma un embotellamiento en la boca de la caseta. Y aquí está lo contraintuitivo: la caseta ahora atiende menos carros por minuto que cuando le mandabas tres ordenados, porque parte de su tiempo se va en gestionar el amontonamiento en vez de en cobrar peajes. Empujar más allá de la capacidad no acelera: congestiona, y la congestión es más lenta que el flujo ordenado.

Un sistema externo —el erp, una API— es esa caseta. Tiene una capacidad: cuántas peticiones puede atender por unidad de tiempo. La concurrencia es cuántos carros mandas a la vez. Hasta la capacidad de la caseta, más concurrencia es más rápido. Pasada la capacidad, más concurrencia es más lento, porque el sistema empieza a rechazar peticiones —"retrocede y vuelve a intentar"— y esos rechazos, con sus reintentos, congestionan todo. La habilidad de esta lección es encontrar el número de carriles de la caseta a la que llamas, y no pasarte.

Qué es un límite de tasa y cómo la API te lo dice

El "número de carriles" de una API tiene un nombre: límite de tasa (rate limit). Es la regla que dice cuántas peticiones aceptará el servicio en una ventana de tiempo. Por ejemplo: "máximo 120 peticiones por minuto". Es una defensa del servicio: sin ella, un solo cliente descuidado —o malicioso— podría saturarlo y dejar sin servicio a todos los demás. El erp de Terra Market tiene uno, como dijimos desde el Módulo 2: "API REST con límite de peticiones por minuto".

Lo importante es que la API te avisa cuando te acercas o te pasas, de dos formas que tienes que saber leer.

Los encabezados que anuncian tu presupuesto. Muchas APIs incluyen, en la respuesta de cada petición, unos encabezados (headers) que te dicen cómo vas con tu presupuesto de llamadas. Los nombres más comunes:

• X-RateLimit-Limit — tu tope total en la ventana (ej. 120).
• X-RateLimit-Remaining — cuántas llamadas te quedan en esta ventana (ej. 43).
• X-RateLimit-Reset — cuándo se reinicia tu presupuesto (una hora o un contador de segundos).

Léelos como el medidor de saldo de una tarjeta de prepago: Limit es cuánto compraste, Remaining es cuánto te queda, Reset es cuándo se recarga. Si Remaining va bajando hacia cero, sabes que estás por chocar con el límite antes de chocar. Para ver estos encabezados en n8n, el nodo HTTP Request tiene una opción —Include Response Headers and Status— que hace que la respuesta traiga también los headers, no solo el cuerpo. Con eso puedes leer tu saldo.

La respuesta que dice "te pasaste": el código 429. Cuando cruzas el límite, la API no te atiende la petición; te responde con el código de estado HTTP 429 — Too Many Requests ("demasiadas peticiones"). Es la caseta diciéndote "retrocede, ahora no". Y casi siempre viene con un encabezado clave:

• Retry-After — cuántos segundos esperar antes de volver a intentar (ej. 30).

Ese Retry-After es un regalo: la API te está diciendo exactamente cuánto esperar para que te vuelva a atender. Ignorarlo y reintentar de inmediato es como empujar el carro contra la pluma cerrada de la caseta: no se va a abrir antes por insistir, y solo congestionas más.

Verifica los nombres en tu API. X-RateLimit-* y Retry-After son los nombres más frecuentes y muchos servicios los usan, pero no son una ley universal: algunas APIs usan variantes (RateLimit-Remaining sin el X-, o nombres propios) o comunican el límite solo en su documentación. El código 429 sí es estándar y casi siempre significa lo mismo. Antes de construir tu manejo de límite de tasa, lee la documentación de tu API para saber qué encabezados manda y qué límite tiene. El concepto es universal; los nombres exactos, no.

La paradoja: más concurrencia, más lento

Aquí está el corazón de la lección, y es lo que la separa de "sube la concurrencia y ya". Vamos a seguir qué pasa exactamente cuando te pasas de los carriles de la caseta, paso a paso, porque la reacción en cadena es lo que hay que entender.

Supón que el erp aguanta cómodo unas 3 peticiones simultáneas (su caseta tiene 3 carriles). Tienes 300 llamadas que hacer. Comparemos dos configuraciones.

Concurrencia moderada (3 a la vez): mandas 3, se atienden, mandas 3 más, se atienden. La caseta trabaja a tope sin congestionarse. Las 300 llamadas fluyen a buen ritmo. Nadie rechaza nada. Terminas en un tiempo razonable.

Concurrencia agresiva (30 a la vez): mandas 30 de golpe a una caseta de 3 carriles. Pasa esto, en orden:

1. Las primeras 3 se atienden. Las otras 27 llegan a un sistema que no las puede atender ya.
2. El erp, para protegerse, responde a muchas de esas con 429 — Too Many Requests. Digamos que 20 de las 30 se rechazan.
3. Esos 20 rechazos son fallos. Y si el nodo HTTP Request tiene Retry On Fail (la capa 1 del Módulo 2), cada uno de esos 20 se reintenta.
4. Los 20 reintentos vuelven a llegar al erp, que sigue saturado, y vuelven a ser rechazados. Más reintentos.
5. Mientras tanto, el erp está gastando su capacidad en rechazar peticiones en vez de en atenderlas, así que hasta las llamadas legítimas van más lento.

El resultado es una tormenta: haces muchas más peticiones que las 300 originales (las 300 + todos los reintentos de los rechazos), el erp pasa su tiempo diciendo "no" en vez de trabajando, y el workflow termina más tarde que con concurrencia moderada —si es que termina, porque puede agotar los reintentos y fallar—. Empujaste más fuerte y avanzaste menos.

    Concurrencia moderada (3):        Concurrencia agresiva (30):

    ███ →  atendidas                  ██████████... → llegan 30
    ███ →  atendidas                  ███ → atendidas (3)
    ███ →  atendidas                  ▓▓▓▓▓▓... → 429 (rechazadas)
    ...    fluye                          │
    ✓ termina a buen ritmo                └─► reintentos ─► más 429 ─► tormenta
                                          ✗ termina más lento (o falla)

La lección de la paradoja, para que no la olvides:

Más concurrencia es más rápido solo hasta la capacidad del otro lado. Pasado ese punto, cada unidad extra de concurrencia produce rechazos, los rechazos producen reintentos, y los reintentos producen más congestión. La curva no sigue subiendo: se da vuelta. El objetivo no es "máxima concurrencia", es "la concurrencia que el otro lado atiende sin rechazar".

Y fíjate en el papel del Retry On Fail: es una capa buenísima para fallos transitorios (Módulo 2), pero frente a un 429 por exceso de concurrencia se vuelve gasolina para el fuego. Reintentar un rechazo por saturación, de inmediato, es garantizar otro rechazo. Por eso los reintentos, cuando la causa es el límite de tasa, tienen que esperar —idealmente lo que diga Retry-After— y no dispararse en seco.

Encontrar el punto sin tumbar el ERP

Ya que el objetivo es "la concurrencia que el otro lado atiende sin rechazar", necesitas un método para encontrarla. Es parecido al de encontrar el tamaño de lote de la lección 3: no se calcula, se busca midiendo, con cuidado y con margen.

Paso 1 — Averigua el límite declarado, si existe. Lo primero, gratis: lee la documentación del erp. Si dice "120 peticiones por minuto", ya tienes un techo de referencia sin haber hecho una sola prueba. Muchas APIs lo publican.

Paso 2 — Empieza bajo, no alto. Al contrario del tamaño de lote, aquí el error caro es empezar alto —congestionas y provocas la tormenta—. Empieza con poca concurrencia (por ejemplo, de a 2 o 3) y observa. Es más seguro subir desde abajo que bajar desde una tormenta.

Paso 3 — Sube de a poco y vigila los rechazos. Aumenta la concurrencia gradualmente y, en cada nivel, mira dos cosas: ¿el tiempo total mejora?, ¿aparecen respuestas 429? Mientras el tiempo mejore y no haya 429, puedes subir. En cuanto empiecen a aparecer 429, te pasaste: baja un escalón. El punto óptimo está justo debajo de donde empiezan los rechazos.

Paso 4 — Deja margen y respeta el reset. Igual que con los lotes, no te quedes justo en el borde. Si a 5 empiezan los 429 y a 4 no, no pongas 4: pon 3. Producción tiene días malos, y el erp "lento en horas pico" (su carácter, desde el Módulo 2) tiene menos capacidad justo cuando más lo usas. Deja aire.

Paso 5 — Si hay 429, honra el Retry-After. Aun con buen margen, algún 429 puede colarse en un pico. Cuando pase, tu reintento debe esperar lo que la API pida, no dispararse de inmediato. Un reintento que respeta Retry-After se recupera; uno que insiste en seco alimenta la tormenta.

Las herramientas de n8n para aplicar esto, sin salir de lo que ya conoces:

• El Batching del nodo HTTP Request (que vimos al final de la lección 5): Items per Batch controla cuántas peticiones agrupa por tanda, y Batch Interval cuánto espera entre tandas. Es una forma directa de decir "de a 3, con una pausa entre grupos".
• El nodo Loop Over Items con lotes chicos, procesando cada tanda antes de la siguiente, para no disparar todo de golpe.
• El nodo Wait, para meter una pausa explícita entre llamadas o entre tandas cuando necesitas espaciarlas más. Su modo After Time Interval (esperar una cantidad de tiempo) es el que sirve aquí; cuando llega un 429 con Retry-After, puedes esperar justo esos segundos antes de reintentar.

Esperar cada vez más: el backoff

Hay un detalle sobre cómo esperar entre reintentos que vale la pena conocer, porque es la diferencia entre un reintento que ayuda y uno que empeora. Se llama backoff exponencial, y la idea es simple: si un reintento falla, el siguiente espera más que el anterior, y así en aumento.

La imagen cotidiana: llamas a alguien y no contesta. No vuelves a marcar cada dos segundos sin parar —eso solo satura su teléfono y te frustra—. Esperas un poco, marcas; si no contesta, esperas un poco más, marcas; y así, dando cada vez más espacio. Si la persona estaba ocupada, los intervalos crecientes le dan tiempo real de desocuparse. Marcar en ráfaga garantiza encontrarla siempre ocupada.

Con un límite de tasa pasa igual. Si el erp te rechazó por saturación, reintentar a intervalos que crecen —1 segundo, luego 2, luego 4— le da tiempo de recuperarse entre uno y otro, y evita que tus reintentos sean parte de la congestión que causó el rechazo. Reintentar en seco, a intervalo fijo y corto, es marcar en ráfaga: llegas siempre en el peor momento. Por eso, cuando la causa del fallo es un 429, la espera creciente le gana a la espera fija, y siempre que la API mande Retry-After, ese valor manda sobre cualquier cálculo tuyo —te está diciendo el momento exacto en que estará lista—.

En n8n puedes construir esto combinando el reintento con esperas: un Wait que crezca entre intentos, o una lógica que lea el Retry-After y espere justo eso. Verifica en tu versión qué ofrece el nodo de reintento de fábrica y complétalo con Wait donde necesites control fino. El concepto —esperar cada vez más— es lo que quiero que te lleves; la implementación exacta la ajustas a las herramientas de tu versión.

Ejemplo trabajado: consultar 500 guías al carrier sin provocar la tormenta

Recuerda el caso que quedó pendiente en la lección 5: el carrier (andes-express) solo ofrece GET /tracking/{guide_id}, de a uno, sin operación masiva. Un workflow consulta 500 guías por corrida. No se pueden agrupar; hay que hacer 500 llamadas. La pregunta es cómo.

El intento ingenuo. Alguien configura el workflow para disparar las 500 con alta concurrencia —"que terminen rápido"—. El carrier, que además es "el más inestable de los cuatro" (Módulo 2), se satura, empieza a responder 429, los reintentos se acumulan, y el workflow termina más lento que nunca —o falla dejando medias guías sin consultar—. La tormenta.

El intento medido. En lugar de eso:

1. Reduce primero (lección 5). ¿De verdad son 500? Las guías "entregadas" ya no cambian de estado. Filtras y quedan 90 "en tránsito". Ya bajaste de 500 a 90 antes de tocar la concurrencia. (Este paso no es de esta lección, pero es el que más ahorra, y va primero.)
2. Lee el límite. La documentación de andes-express dice "60 peticiones por minuto". Ese es tu techo: 60/min ≈ 1 por segundo.
3. Configura para respetarlo. Con Batching en el HTTP Request —o con Loop Over Items + Wait— haces las 90 llamadas a un ritmo de, digamos, 1 por segundo (con margen bajo el límite de 60/min). Las 90 tardan alrededor de 90 segundos, fluidas, sin un solo 429.
4. Prepara el 429 por si acaso. Le pones Retry On Fail al nodo, pero con espera —y si llega un 429 con Retry-After, un Wait que honre esos segundos antes de reintentar—.

Qué esperar. El intento medido tarda alrededor de minuto y medio y termina siempre. El intento ingenuo, con suerte, tarda parecido en un día bueno, y en un día malo entra en la tormenta y tarda mucho más o falla. La diferencia no es de velocidad en el mejor caso —son parecidos—; es de estabilidad: el intento medido no tiene días malos, porque nunca empuja al carrier más allá de su capacidad. En producción, "siempre termina en 90 segundos" le gana a "a veces 60, a veces falla". Y fíjate en el orden: lo que más ahorró no fue la concurrencia fina, fue reducir de 500 a 90 en el paso 1. La concurrencia gestionó bien las 90 que quedaban; la reducción eliminó las 410 que no hacían falta.

Un apunte sobre la concurrencia de la propia instancia de n8n

Hasta aquí hablamos de la concurrencia hacia afuera: cuántas llamadas simultáneas le haces a una API. Hay otra concurrencia, distinta, que conviene nombrar para no confundirlas: la de la propia instancia de n8n, o sea cuántas ejecuciones corre n8n al mismo tiempo.

n8n tiene una variable de entorno, N8N_CONCURRENCY_PRODUCTION_LIMIT, que limita cuántas ejecuciones de producción corren a la vez. Cuando se llega al límite, las ejecuciones nuevas no se pierden: esperan en cola y arrancan en orden cuando se libera capacidad (eso es, exactamente, la "cubeta de cola" de la lección 2). Su valor por defecto y su comportamiento dependen de la edición y del modo (regular o cola), así que verifica el número vigente para tu instancia en la documentación en vez de asumirlo.

Esto es infraestructura, no diseño de workflow. N8N_CONCURRENCY_PRODUCTION_LIMIT es un ajuste de la instancia, del lado del servidor, y su territorio es la guía de self-hosting y operaciones, no esta. Lo menciono por dos razones. Una: para que no confundas "cuántas llamadas hago a la vez a una API" (lo de esta lección, que sí controlas desde el workflow) con "cuántas ejecuciones corre n8n a la vez" (infraestructura). Dos: porque ese límite de instancia es una de las señales de la lección 7 —si tus ejecuciones pasan mucho tiempo en cola esperando turno, es indicio de que la instancia, no el workflow, es el cuello—. Aquí, en cambio, trabajamos la concurrencia hacia afuera, que es una decisión de diseño del workflow y se resuelve con Batching, Loop Over Items y Wait.

Errores comunes

Subir la concurrencia al máximo "para que termine rápido" (conceptual). Qué pasa: se configura la máxima concurrencia posible con la lógica de "más paralelo, más rápido", y el sistema externo se satura, responde 429, y el workflow termina más lento o falla. Por qué pasa: la intuición de que más paralelo siempre es más rápido es cierta solo hasta la capacidad del otro lado, y esa capacidad es invisible hasta que la cruzas. Cómo detectarlo: si ves respuestas 429 en tus ejecuciones, o si subir la concurrencia empeoró el tiempo en vez de mejorarlo, cruzaste el punto. Cómo corregirlo: baja la concurrencia hasta que desaparezcan los 429 y deja margen. El objetivo no es máxima concurrencia, es máxima concurrencia que el otro lado atiende sin rechazar.

Reintentar un 429 de inmediato (práctico). Qué pasa: el nodo tiene Retry On Fail sin espera, llega un 429, y el reintento se dispara al instante contra un servicio que sigue saturado, provocando otro 429, y otro. Por qué pasa: Retry On Fail es la solución correcta para fallos transitorios (Módulo 2), y es fácil olvidar que un 429 no es un fallo transitorio cualquiera: es "espera antes de volver". Cómo detectarlo: si tus reintentos ante 429 fallan una y otra vez, los estás disparando demasiado pronto. Cómo corregirlo: haz que el reintento espere —lo que diga Retry-After si está, o un tiempo prudente si no— antes de volver. Un Wait o una configuración de reintento con espera creciente. Reintentar sin esperar un 429 es empujar la pluma cerrada de la caseta.

Ignorar los encabezados que la API te regala (práctico). Qué pasa: la API manda X-RateLimit-Remaining en cada respuesta —te dice cuánto saldo te queda— y el workflow no los lee, así que choca con el límite a ciegas cuando podría haberlo visto venir. Por qué pasa: por defecto el nodo HTTP Request devuelve solo el cuerpo, no los encabezados, así que hay que activarlos a propósito y mucha gente no sabe que están ahí. Cómo detectarlo: si manejas una API con límite de tasa y no lees sus headers, estás volando sin instrumentos. Cómo corregirlo: activa Include Response Headers and Status en el nodo para recibir los encabezados, y úsalos para regular el ritmo antes de chocar. Es información gratis que la API te da; no leerla es desperdiciarla.

Afinar la concurrencia antes de reducir las llamadas (conceptual). Qué pasa: se dedica esfuerzo a encontrar el número mágico de concurrencia para 300 llamadas que, con la lección 5, habrían sido 3. Por qué pasa: la concurrencia es un problema entretenido de resolver y se salta el paso aburrido de preguntar si las llamadas eran necesarias. Cómo detectarlo: si estás calibrando concurrencia sin haber verificado que la API no ofrece batch y que no consultas de más, te saltaste el paso de mayor impacto. Cómo corregirlo: primero reduce (lección 5); después calibra el ritmo de las que queden. Tres llamadas ni siquiera necesitan gestión de concurrencia; trescientas sí, pero mejor que sean tres.

Confundir la concurrencia hacia afuera con el límite de la instancia (conceptual). Qué pasa: alguien lee sobre N8N_CONCURRENCY_PRODUCTION_LIMIT y cree que ajustándolo va a controlar cuántas llamadas le hace su workflow al erp. Son cosas distintas: esa variable limita cuántas ejecuciones corre n8n, no cuántas peticiones hace una ejecución a una API. Por qué pasa: las dos usan la palabra "concurrencia". Cómo detectarlo: pregúntate si quieres controlar "cuántas cosas hace n8n a la vez" (variable de instancia, infraestructura) o "cuántas llamadas simultáneas le hago a una API" (diseño del workflow, esta lección). Cómo corregirlo: para el ritmo de las llamadas a una API, usa Batching, Loop Over Items y Wait dentro del workflow. La variable de instancia es otra conversación, de la guía de self-hosting.

Ejercicios

Ejercicio 1 — Lee el medidor. Una respuesta del erp trae estos encabezados. Interpreta cada uno y di qué harías.

X-RateLimit-Limit: 120
X-RateLimit-Remaining: 8
X-RateLimit-Reset: 25

Ver solución

• X-RateLimit-Limit: 120 — tu tope es 120 peticiones en la ventana actual.
• X-RateLimit-Remaining: 8 — te quedan solo 8 antes de chocar con el límite.
• X-RateLimit-Reset: 25 — tu presupuesto se recarga en 25 segundos.

Qué haría: estoy al borde. Con solo 8 llamadas de saldo y todavía por hacer, si sigo al ritmo actual voy a recibir 429 en breve. Lo prudente es frenar: espaciar las próximas llamadas, o hacer una pausa hasta que el Reset recargue el presupuesto en 25 segundos. Este es justo el valor de leer los encabezados: veo el choque venir con 8 de anticipación y puedo evitarlo, en vez de descubrirlo cuando ya me rechazaron.

Por qué funciona: Remaining es tu instrumento de vuelo. Bajando hacia cero es una luz amarilla; si la ignoras, la roja (el 429) llega sola. Leerlo convierte el límite de tasa de una sorpresa en algo que administras.

Ejercicio 2 — Explica la paradoja. Un compañero dice: "puse la concurrencia en 50 para que las 400 llamadas al erp terminaran rápido, pero ahora tarda más que cuando estaba en 4 y veo un montón de errores 429. No entiendo, ¿más paralelo no era más rápido?". Explícale qué está pasando, en términos de la caseta de peaje.

Ver solución

Le diría: el erp es una caseta de peaje con pocos carriles —digamos que atiende bien unas 4 peticiones a la vez—. Cuando le mandas 4, llena sus carriles y trabaja a tope: fluye. Cuando le mandas 50, no caben: atiende 4 y a las otras 46 les dice "no puedo, retrocede" —eso es el 429—. Esos 46 rechazos se reintentan, vuelven a llegar, vuelven a rechazarse, y el erp se la pasa diciendo "no" en vez de atendiendo. La caseta ahora gasta su tiempo gestionando el amontonamiento, así que atiende menos peticiones por minuto que cuando le mandabas 4 ordenadas. Por eso tardó más con 50 que con 4: no la aceleraste, la congestionaste.

Qué hacer: bajar la concurrencia a un número donde no aparezcan 429 —probablemente cerca de 4, con margen— y, si algún 429 se cuela, que los reintentos esperen antes de volver. "Más paralelo es más rápido" es verdad solo hasta la capacidad de la caseta; pasada esa, se invierte.

Por qué funciona: la clave es que la capacidad la pone el erp, no tu configuración. Tú no decides cuántos carriles tiene la caseta; solo decides si respetas ese número o lo ignoras. Ignorarlo no agranda la caseta, solo arma el embotellamiento.

Ejercicio 3 — Ordena la solución completa. Un workflow tiene que actualizar el estado de 800 pedidos en el erp, uno por uno (el erp no ofrece actualización masiva para esta operación), y hoy lo hace con concurrencia alta y falla seguido con 429. Escribe el plan completo, en orden de prioridad, combinando lo que sabes de las lecciones 5 y 6.

Ver solución

El plan, en orden:

1. Reducir el N (lección 5). ¿De verdad hay que actualizar los 800, o solo los que cambiaron desde la última corrida? Si solo 120 cambiaron, actualizo 120. La llamada que no hago no puede saturar nada. Este paso, aunque es de la lección anterior, va primero porque es el de mayor impacto.

2. Verificar si de verdad no hay operación masiva (lección 5). Confirmo en la documentación que este endpoint específico no acepta varios pedidos. A veces uno asume que no hay batch y sí lo hay para esta operación.

3. Leer el límite de tasa (lección 6). Averiguo el tope del erp (por documentación o por los encabezados X-RateLimit-*) para saber a qué ritmo puedo ir.

4. Bajar la concurrencia y espaciar (lección 6). Configuro Batching o Loop Over Items + Wait para hacer las llamadas restantes a un ritmo por debajo del límite, empezando bajo y subiendo solo mientras no aparezcan 429, con margen.

5. Preparar el 429 (lección 6). Retry On Fail con espera, y si llega Retry-After, honrarlo antes de reintentar.

Resultado: de 800 llamadas atropelladas que fallan, a ~120 llamadas ordenadas que siempre terminan.

Por qué funciona: el orden va de mayor a menor impacto y de eliminar a gestionar. Primero se quitan las llamadas que sobran (pasos 1-2), después se hacen bien las que quedan (pasos 3-5). Empezar por el paso 4 —afinar la concurrencia de las 800— sería optimizar el ritmo de cientos de llamadas que ni siquiera había que hacer.

Resumen y siguiente paso

En esta lección viste la concurrencia con la imagen de la caseta de peaje: tantos carros en paralelo como carriles tenga la caseta la hacen fluir a tope, pero un carro más de la cuenta la congestiona y la vuelve más lenta. Aprendiste qué es un límite de tasa —cuántas peticiones acepta una API por ventana de tiempo— y cómo la API te lo comunica: los encabezados X-RateLimit-* que te muestran tu saldo, y el código 429 con su Retry-After que te dice cuánto esperar cuando te pasaste (verifica los nombres exactos en tu API; el 429 sí es estándar). Entendiste la paradoja que engaña a tanta gente: pasada la capacidad del otro lado, más concurrencia produce rechazos, los rechazos producen reintentos, y todo se vuelve más lento —y por qué un Retry On Fail sin espera echa gasolina al fuego ante un 429—. Y te quedaste con el método para encontrar el punto: lee el límite, empieza bajo, sube de a poco vigilando los 429, deja margen, y honra el Retry-After, con las herramientas que ya conoces —Batching, Loop Over Items, Wait—. Cerramos distinguiendo esta concurrencia hacia afuera de la de la propia instancia (N8N_CONCURRENCY_PRODUCTION_LIMIT), que es infraestructura y anticipa la frontera de la próxima lección.

Antes de avanzar deberías poder: explicar la paradoja de la concurrencia con la caseta; nombrar los encabezados de límite de tasa y el código 429 con su Retry-After; y decir por qué reducir llamadas (lección 5) va antes que gestionar el ritmo (lección 6).

Con esta lección cierras las técnicas de optimización del workflow. Mediste (L2), loteaste (L3), cuidaste la memoria (L4), redujiste llamadas (L5) y encontraste el ritmo (L6). Llega el momento honesto: ¿y si hiciste todo esto y el workflow —o el conjunto de tus workflows— sigue sin dar abasto? La lección 7 es la frontera del módulo. Enseña a reconocer, con evidencia, el punto en que el cuello ya no está en el workflow sino en la instancia —cuando las ejecuciones esperan turno en cola, cuando varios workflows simultáneos saturan la máquina—, qué medir para probarlo antes de gastar en infraestructura, y cuándo cruzar a la guía de self-hosting a montar el modo cola. Es el único momento del módulo en que la respuesta correcta puede ser, de verdad, "sí, ahora sí toca más máquina".

Recursos

• HTTP Request node — n8n Docs — sus opciones Batching (Items per Batch, Batch Interval) para espaciar peticiones, e Include Response Headers and Status para leer los encabezados de límite de tasa.
• Wait node — n8n Docs — el nodo para meter pausas entre llamadas o reintentos; su modo After Time Interval es el que sirve para respetar un Retry-After.
• Control concurrency — n8n Docs — la variable N8N_CONCURRENCY_PRODUCTION_LIMIT de la instancia (infraestructura, self-hosting); verifica aquí su valor por defecto y comportamiento vigentes.
• HTTP status 429 Too Many Requests — MDN — la referencia del código estándar con el que las APIs anuncian que cruzaste su límite de tasa, y del encabezado Retry-After.