Módulo 1: Triggers Avanzados

Polling vs Event-Based: Cuándo Cada Uno

Descripción de la cápsula

Casi todos los triggers que has visto caen en una de dos categorías subyacentes: polling (mi workflow consulta cada cierto tiempo) o event-based / push (el servicio externo me avisa). Esta diferencia técnica tiene consecuencias prácticas importantes: latencia, costo, complejidad de setup, confiabilidad, y deuda técnica a largo plazo.

En esta cápsula vas a aprender los trade-offs concretos entre polling y push, los 5 factores que guían la elección, ejemplos de cuándo cada uno es la decisión correcta, y los errores comunes que llevan a workflows frágiles.

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

✅ Distinguir polling de event-based en cualquier trigger
✅ Aplicar 5 factores de decisión al caso específico
✅ Cuantificar trade-offs de latencia, costo, complejidad
✅ Identificar errores comunes en cada estrategia
✅ Diseñar soluciones híbridas cuando aplique

El modelo conceptual

Polling

Tu workflow es un cliente impaciente. Cada X tiempo pregunta al servicio "¿hay novedades?". El servicio responde sí o no. Si sí, tu workflow procesa.

El servicio no avisa por iniciativa propia — solo responde cuando le preguntan.

Ejemplos:

Gmail Trigger en modo polling (chequea Gmail cada 1 min)
RSS Feed Trigger (consulta feed cada X tiempo)
HTTP Request en Schedule (tú implementas polling manual)
Google Sheets Trigger en modo polling

Push (Event-Based)

Tu workflow es pasivo. Se queda escuchando. El servicio le avisa apenas pasa algo.

No hay consultas — la comunicación va del servicio al workflow.

Ejemplos:

Webhook Trigger genérico
Slack Trigger con configuración real-time
Stripe Trigger (Stripe te manda push)
GitHub Trigger

Comparación directa

Dimensión	Polling	Push
Latencia	Alta (depende del intervalo)	Baja (instantánea)
Costo (ejecuciones)	Alto (consume cada vez aunque no haya cambios)	Bajo (solo dispara cuando hay evento)
Costo (API quota)	Alto (consultas frecuentes)	Bajo (no consultas)
Complejidad setup	Baja	Media (configurar webhook en el servicio)
Confiabilidad	Alta (si polling falla 1x, se recupera al siguiente)	Media (si webhook falla, se pierde el evento)
Mantenibilidad	Sin dependencias externas que cambien	Webhooks pueden romperse si el servicio cambia
Disponibilidad	Funciona con cualquier servicio que tiene API	Solo si el servicio expone webhooks/events

Los 5 factores de decisión

Factor 1: ¿Cuál es la latencia tolerable?

<1 min: push obligatorio (polling no alcanza esa velocidad)
1-5 min: push preferible, polling funciona
5-30 min: ambos OK
>30 min: polling es perfectamente adecuado

Factor 2: ¿Qué tan frecuente es el evento?

Eventos raros (1-10/día): push es óptimo — polling desperdicia 99% de las consultas
Eventos frecuentes (>100/día): polling puede ser más eficiente (batch-procesar lo acumulado)
Eventos esporádicos pero impredecibles: push (no sabes cuándo viene)

Factor 3: ¿El servicio soporta push?

Sí (Slack, GitHub, Stripe, Tally, etc.): usar push
No (algunos legacy systems, Sheets en algunos modos): polling es la única opción

Factor 4: ¿Cuál es tu plan de n8n / API quotas?

Plan limitado en ejecuciones: push ahorra ejecuciones
Plan limitado en API calls a otro servicio: push ahorra calls
Plan generoso: polling más simple, menos preocupación

Factor 5: ¿Necesitas alta confiabilidad?

Crítica (transacciones, pagos): considera ambos en paralelo — webhook + polling como backup
Importante pero no crítica: push solo, monitoreo periódico
Best effort: push solo

Decisiones concretas en casos típicos

Caso 1: Notificar cuando un nuevo cliente paga en Stripe

Recomendado: Push (Stripe Webhook / Stripe Trigger)
Por qué: pagos son críticos, necesitas reacción inmediata, Stripe soporta perfectamente

Caso 2: Procesar nuevas filas en Google Sheets

Recomendado: Polling (Google Sheets Trigger)
Por qué: Sheets no manda push real, polling cada 5-15 min suele alcanzar

Caso 3: Sync de leads de un CRM legacy con API REST

Recomendado: Polling con Last Modified > X filter
Por qué: CRM legacy probablemente no tiene webhooks; polling con filter es estándar

Caso 4: Auto-responder a emails de soporte

Recomendado: Polling (Gmail Trigger, default ~1 min)
Por qué: Gmail no expone push público; 1 min de latencia es aceptable para emails

Caso 5: Reaccionar a deploys en GitHub

Recomendado: Push (GitHub Webhook / GitHub Trigger)
Por qué: GitHub tiene webhooks nativos perfectos; ideal para CI/CD-like flows

Caso 6: Resumen diario de actividad

Recomendado: Schedule Trigger (no polling ni push — time-based)
Por qué: no estás reaccionando a eventos, estás generando reporte programado

Diseños híbridos

A veces la solución correcta combina ambos:

Híbrido 1: Push + polling de respaldo

Trigger principal: Webhook (push)
Trigger respaldo: Schedule diario que verifica si hubo eventos perdidos

Cuándo: sistemas críticos donde no puedes permitirte perder eventos. Webhooks pueden fallar (red, downtime de n8n) — el polling diario captura cualquier evento perdido.

Híbrido 2: Polling con resumen push

Polling cada hora para procesar items
Webhook push para emergencias (cancel urgente, error crítico)

Cuándo: servicio tiene polling regular + capacidad de push para casos urgentes.

Híbrido 3: Push real-time + procesamiento batch

Webhook: registra el evento en una queue (Sheet, DB)
Schedule cada hora: procesa la queue acumulada

Cuándo: llegan eventos frecuentes que no necesitan procesamiento inmediato — los acumulas y procesas batch.

Errores comunes

Error 1: Polling muy frecuente "por si acaso"

Qué pasa: Configuras polling cada 1 min "para asegurar". El servicio recibe 60 consultas/hora del mismo workflow.

Por qué es problema:

Rate limits del servicio
Tu plan de n8n se queda sin ejecuciones
Costos en APIs pagas

Cómo evitar: calcula la latencia tolerable y ajusta. La mayoría de los casos toleran 5-15 min.

Error 2: Push sin manejo de duplicados

Qué pasa: Stripe te manda el webhook 2 veces (porque la primera respuesta no llegó). Tu workflow crea 2 registros para el mismo pago.

Por qué es problema: webhooks at-least-once — pueden duplicarse. Polling no tiene este issue tan agudo.

Cómo evitar:

Usar idempotency keys (Stripe los manda en event.id)
Verificar antes de procesar: "¿ya procesé este event.id?"

Error 3: Polling sin estado (siempre relee todo)

Qué pasa: Polling Sheet con todas las filas cada vez. Procesas las 1000 filas en cada ejecución, no solo las nuevas.

Cómo evitar:

Usar trigger con detección de cambios (los buenos triggers de polling lo hacen)
O agregar columna procesado y filtrar solo las no procesadas
O usar timestamp Last Modified para filter

Error 4: Push sin retry strategy

Qué pasa: Webhook llega a tu n8n, pero n8n estaba caído 30 segundos. El evento se pierde. El servicio no reintenta.

Por qué es problema: webhooks pueden perderse si el receptor no está disponible.

Cómo evitar:

Servicios pro (Stripe, GitHub) reintentan automáticamente
Si no reintentan, considera híbrido push + polling
Asegurar uptime de n8n (en self-hosted)

Error 5: No documentar cuál estrategia usa el workflow

Qué pasa: Pasas el workflow al equipo. 6 meses después, alguien pregunta "¿por qué este workflow tarda 5 min en responder?". Nadie recuerda que es polling con interval 5 min.

Cómo evitar: Sticky Note en el canvas que dice "Polling cada 5 min. Latencia hasta 5 min normal."

Métricas para monitorear

Si tienes workflows críticos, monitorea:

Para polling

Ratio de ejecuciones útiles: % de polls que encontraron datos vs vacíos
Si la ratio es <5%, considera bajar frecuencia
Quota usage: % de API quota consumida — escalar plan si necesario

Para push

Webhooks recibidos vs esperados: discrepancia indica pérdida
Latencia de procesamiento: desde que llega webhook hasta que termina el workflow
Duplicados: count de events con mismo event.id

Ejercicio: clasificar 5 casos

Objetivo: practicar la decisión polling vs push.

Tu tarea

Para cada caso, decide: Polling, Push, o Híbrido. Justifica.

Alertar al equipo cuando alguien deja review en Trustpilot (la página tiene RSS feed pero no API)
Reaccionar a comentarios nuevos en un blog WordPress
Detectar nuevos archivos en una carpeta de Dropbox
Procesar pagos cuando llegan vía Stripe
Mantener sync entre tu Notion database y Airtable (cambios en ambos lados)

Ver respuestas sugeridas

Polling del RSS — único método disponible. Frecuencia: 1h alcanza.
Push si tienes plugin de WordPress que webhook (Jetpack, etc.). Polling si no tienes ese setup.
Push con Dropbox Trigger nativo. Dropbox lo soporta bien.
Push con Stripe Trigger (HMAC validado). Híbrido si pagos son críticos — agregar polling diario como respaldo.
Híbrido: push de ambos lados (Notion + Airtable) + reconciliación diaria por polling para detectar conflictos.

Resumen y siguiente paso

Polling: tu workflow pregunta. Push: el servicio avisa.
5 factores de decisión: latencia tolerable, frecuencia evento, soporte del servicio, plan/quotas, confiabilidad requerida
Push suele ganar para eventos importantes — push es más eficiente cuando hay soporte
Polling es la única opción cuando no hay push, o cuando la frecuencia es muy baja
Diseños híbridos para casos críticos: push principal + polling como red de seguridad
5 errores: polling muy frecuente, push sin idempotency, polling sin estado, push sin retry, no documentar estrategia

Antes de avanzar deberías poder:

Decidir polling vs push para cualquier caso de negocio
Reconocer cuándo un diseño híbrido aporta valor
Identificar los errores comunes en cada estrategia

Lo que sigue (cápsula 07):

A veces un solo trigger no alcanza — necesitas que el workflow se dispare por múltiples eventos (Schedule + Webhook + Manual). La cápsula 07 te enseña a combinar triggers en un workflow sin que se vuelva caótico.

Recursos adicionales

Polling vs Webhooks (Zapier comparison) - Análisis general.
Webhook Reliability Best Practices - Patrones de retry y idempotency.
Idempotency in Stripe API - Cómo Stripe maneja duplicados.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorDisparadores por eventos de apps (Gmail, Slack, Calendar)Siguiente →Combinar Múltiples Triggers en un Workflow