Los sistemas funcionales son pequeños patrones y nodos que hacen que tus flujos sean más robustos, escalables y mantenibles.
Son como los tornillos de una máquina: pequeños pero esenciales.
Un buffer acumula múltiples items antes de procesarlos juntos. Útil para optimizar llamadas a APIs o bases de datos.
Trigger → Split In Batches (batch size: 50) → Proceso → Loop Cada iteración procesa 50 items Espera entre batches para no sobrecargar
Batch Size: 50 // Items por batch Options: - Reset: false // Continuar donde quedó - Pause Between: 1s // Esperar entre batches (rate limiting)
• Usa "Pause Between Batches" para respetar rate limits de APIs
• Combínalo con Error Handling para reintentar batches fallidos
• El batch size ideal depende de la API (revisa su documentación)
El nodo Merge combina datos de dos o más ramas de tu flujo. Esencial cuando necesitas juntar información de diferentes fuentes.
Rama 1 (Clientes):
[{id: 1, name: "Juan"}, {id: 2, name: "Ana"}]
Rama 2 (Pedidos):
[{customer_id: 1, total: 100}, {customer_id: 2, total: 200}]
Merge (Combine by: id = customer_id):
[{id: 1, name: "Juan", total: 100}, {id: 2, name: "Ana", total: 200}]
💡 Caso común: Tienes dos APIs (clientes y pedidos) y necesitas combinar la información para generar un reporte unificado.
Switch Node:
Field: {{ $json.customer_type }}
Rules:
- "vip" → Rama 1 (Atención prioritaria)
- "normal" → Rama 2 (Proceso estándar)
- "trial" → Rama 3 (Onboarding especial)
- default → Rama 4 (Revisar manualmente)
// Solo emails de Gmail
{{ $json.email.includes('@gmail.com') }}
// Solo pedidos mayores a $100
{{ $json.total > 100 }}
// Solo registros con campo no vacío
{{ $json.name !== '' && $json.name !== null }}
// Múltiples condiciones
{{ $json.status === 'active' && $json.age >= 18 }}
💡 Pro Tip: Usa Filter al inicio de tus flujos para eliminar datos basura antes de procesarlos. Ahorra tiempo y recursos.
El nodo Wait pausa la ejecución por un tiempo específico o hasta que ocurra un evento externo.
1. Usuario solicita vacaciones 2. Enviar email al manager con link de aprobación 3. WAIT for Webhook (espera clic en "Aprobar" o "Rechazar") 4. Procesar respuesta y notificar al usuario
Los nodos Wait en modo webhook mantienen la ejecución "pausada" en n8n. Si tienes muchos flujos pausados, puede afectar el rendimiento. Considera usar un sistema de colas externo para flujos de larga duración.
Los errores van a pasar. La pregunta es: ¿tu flujo está preparado? Un buen manejo de errores convierte un flujo frágil en uno robusto.
En el nodo → Settings → On Error: - "Stop Workflow" (default) - "Continue" (salta al siguiente item) - "Continue (using error output)" (envía error a otra rama) En Workflow Settings: - Error Workflow: Selecciona un workflow que reciba los errores
Settings → Retry On Fail: - Max Tries: 3 - Wait Between Tries: 1000ms (1 segundo) - Backoff: Exponential (1s, 2s, 4s...)
💡 Exponential Backoff: Cada reintento espera más tiempo. Esto evita sobrecargar un servidor que está teniendo problemas.
✅ Errores temporales: - 500, 502, 503, 504 (server errors) - Timeouts - Rate limits (429) ❌ NO usar retry para: - 400 Bad Request (tu request está mal) - 401/403 (problema de auth) - 404 Not Found (el recurso no existe)
URL: https://tu-n8n.com/webhook/stripe-payments
Stripe envía:
{
"type": "payment_intent.succeeded",
"data": {
"object": {
"amount": 2000,
"customer": "cus_123..."
}
}
}
Tu flujo:
Webhook → IF (type == "payment_intent.succeeded") → Actualizar DB
• Valida la firma del webhook (Stripe, GitHub envían headers de verificación)
• Usa HTTPS siempre
• Limita los IPs que pueden llamar si es posible
• No expongas información sensible en la URL
La mayoría de APIs tienen límites: 100 requests/minuto, 1000/hora, etc. Si los excedes, te bloquean. Rate limiting evita esto.
Opción 1: Wait Node Loop → Wait (500ms) → HTTP Request → Loop Opción 2: Split In Batches Split In Batches → HTTP Request Options: Pause Between Batches = 1000ms Opción 3: Code Node (avanzado) await new Promise(resolve => setTimeout(resolve, 500));
Una cola almacena tareas para procesarlas después, una por una. Perfecto cuando recibes muchos eventos y no puedes procesarlos todos al instante.
Flujo 1 (Productor): Webhook → Redis (LPUSH "tasks" task_data) Flujo 2 (Consumidor): Schedule Trigger (cada 5s) → Redis (RPOP "tasks") → IF (hay tarea) → Procesar → Loop
• Desacoplan productor y consumidor
• Manejan picos de tráfico sin perder datos
• Permiten reintentos si el procesamiento falla
• Escalan horizontalmente (múltiples workers)
💡 Pro Tip: Combina estos nodos para crear transformaciones de datos complejas. Filter → Sort → Limit → Set es un patrón muy común.
✅ Webhook (entrada de datos)
✅ Filter (limpieza de datos)
✅ Switch (enrutamiento condicional)
✅ Retry (resiliencia en APIs)
✅ Merge (combinar datos)
✅ Batching (optimización)
✅ Error Handling (robustez)