Manteníamos distintas categorías de contactos (equipo interno, canal de revendedores, y clientes finales) en libretas separadas de Google Contacts. Cada una necesitaba llegar a dos lugares más: al LDAP corporativo, para que los teléfonos IP muestren el nombre correcto en cada llamada, y a Chatwoot, para que el equipo de soporte tenga el contexto completo de con quién está hablando. Necesitábamos un solo proceso automático, corriendo sobre n8n, que tomara Google Contacts como única fuente de verdad y empujara los cambios hacia los otros dos sistemas de forma confiable.

Diagrama simplificado del flujo: una sola fuente de verdad, tres destinos.

El orquestador que corre esta sincronización es el mismo que atiende, en tiempo real, las conversaciones de nuestros bots de soporte. Eso significa que cualquier proceso pesado —traer y procesar cientos de contactos de una sola vez— compite por memoria y CPU con el tráfico real de clientes. No podíamos «probar en productivo y ver qué pasa»: cualquier corrida que se pasara de recursos podía tirar abajo el proceso que sostiene la atención al cliente.

La primera hipótesis frente a los cuelgues de memoria fue ajustar una variable de entorno pensada justamente para eso. La subimos varias veces, sin resultado — el límite de memoria real no se movía un milímetro. Investigando el proceso de arranque interno del motor de ejecución, encontramos la causa real: esa variable ni siquiera llegaba a aplicarse (el lanzador interno filtra qué variables reenvía al proceso, y esa no estaba en la lista). El techo real lo pone el límite de memoria del propio contenedor Docker, porque el motor de JavaScript autoajusta su heap a un porcentaje de esa memoria disponible.

La solución no fue «una variable mágica», sino tocar el límite real, por configuración externa, con un patrón que evita repetir la misma configuración en cada servicio:

# Un solo bloque de recursos, compartido por todos los workers.
# Subir la memoria acá alcanza para todos los servicios que lo referencian.
x-worker-common: &worker-common
  deploy:
    resources:
      limits:
        memory: 1536M   # antes

services:
  worker-1:
    <<: *worker-common
  worker-2:
    <<: *worker-common
  worker-3:
    <<: *worker-common
  worker-4:
    <<: *worker-common

Con este patrón, subir el límite es cambiar una sola línea del ancla compartida — y como cada cambio de infraestructura se probó reiniciando los contenedores de a uno (con chequeo de salud entre cada reinicio), pudimos aplicarlo sin ningún corte de servicio.

La cuenta más grande de contactos seguía sin poder sincronizarse de punta a punta, incluso con más memoria disponible: pedía toda su página de contactos (hasta mil registros) en un solo pedido a la API, y esos datos crudos —más su versión ya procesada— convivían en memoria durante toda la ejecución. La solución de fondo no fue «más memoria», fue rediseñar el pedido para que nunca sostenga más de un puñado de contactos a la vez.

Intentamos primero resolverlo con un loop interno dentro de un único nodo de código, pero el motor de automatización no permite hacer llamadas autenticadas a APIs externas desde ese tipo de nodo (una limitación real que descubrimos con una prueba aislada, sin tocar nada productivo). Así que en vez de paginar dentro de una ejecución, pasamos a paginar entre corridas programadas: cada corrida trae un lote acotado y guarda en base dónde se quedó, para que la próxima retome sola.

// Se arma el pedido combinando: tamaño de página acotado,
// más el token de sincronización o de página, si ya existen.
JSON.stringify(Object.assign(
  {
    personFields: 'names,phoneNumbers,emailAddresses,organizations',
    pageSize: 500,          // nunca más de esto por corrida
    requestSyncToken: true
  },
  (syncToken ? { syncToken } : {}),
  (pageToken ? { pageToken } : {})
));

Fragmento simplificado de la construcción del pedido a la API de contactos.

El resultado: cada corrida programada procesa un lote chico y acotado, nunca compite en memoria consigo misma, y una cuenta que antes no lograba sincronizar ni una vez completó su primer recorrido en un puñado de corridas sucesivas — sin tocar el límite de memoria más allá del ajuste moderado del punto anterior.

Ya con el pipeline corriendo de punta a punta, hicimos una verificación cruzada contra los tres sistemas (no nos alcanzó con ver «ejecución exitosa»). Encontramos que el directorio interno y el LDAP quedaban perfectos, pero Chatwoot solo recibía 1 de cada 10 contactos nuevos por corrida. La causa: un nodo de código que decide «¿este contacto ya existe o hay que crearlo?» corría en el modo por defecto del motor de automatización — que ejecuta el código una sola vez para todo el lote — pero el código adentro solo miraba el primer ítem del lote, descartando el resto en silencio.

// $json en este modo apunta SOLO al primer ítem de entrada.
// Si llegan 10 contactos, los otros 9 nunca se evalúan.
const searchResp = $json;
const orig = $('Preparar Contacto').item.json;
// ... arma UN solo resultado ...
return [{ json: { existeMatch, matchedContactId } }];

// Se recorre explícitamente CADA ítem de entrada,
// devolviendo un resultado por cada uno, en el mismo orden.
const origItems = $('Preparar Contacto').all();
const searchItems = $input.all();
const out = [];
for (let i = 0; i < searchItems.length; i++) {
  const searchResp = searchItems[i].json;
  const orig = origItems[i].json;
  // ... misma lógica de siempre, ahora aplicada a cada uno ...
  out.push({ json: { existeMatch, matchedContactId } });
}
return out;

• Un «success» en el log no confirma que los tres sistemas de destino recibieron los datos — hay que verificar cruzado, contra la base real, no solo contra el estado de la ejecución.
• Los techos de memoria «misteriosos» casi siempre tienen una causa aburrida y verificable: leer cómo arranca el proceso, no solo ajustar variables por prueba y error.
• Paginar en origen (pedir de a poco) resuelve problemas de memoria de raíz, mejor que escalar recursos como primera respuesta.
• Todo cambio de infraestructura compartida con producción se prueba de a un componente por vez, con verificación de salud entre cada paso.
• Los nodos de código en plataformas low-code esconden un modo de ejecución «por lote completo» que es fácil de usar mal — probarlo siempre con más de un ítem antes de confiar en él.