Módulo 5: Scheduling y Tiempo

Scheduling Dependiente: Workflows en Cadena

Descripción de la cápsula

A veces no quieres workflows independientes — quieres workflows que se ejecutan en cadena, donde el segundo espera a que el primero termine. Ejemplo: workflow A genera datos a las 6am, workflow B procesa esos datos a las 7am (asumiendo que A ya terminó), workflow C envía reporte a las 8am.

Hay varias formas de hacer scheduling dependiente. En esta cápsula vas a ver las 3 estrategias principales, sus trade-offs, y cuándo usar cada una.

Lo que vas a aprender

✅ Estrategia 1: Schedule offset — workflows con horarios escalonados
✅ Estrategia 2: Execute Workflow al final — chain explícita
✅ Estrategia 3: Webhook + Schedule mixto — más robusto
✅ Decidir entre las 3 según el caso

Estrategia 1: Schedule offset (más simple)

Workflows independientes con schedules escalonados que dejan tiempo entre cada uno.

A: 6:00 AM (estimas tarda 30 min)
B: 7:00 AM (asume A terminó)
C: 8:00 AM (asume B terminó)

Pros

Simple — sin coupling entre workflows
Workflows independientes (puedes desactivar uno sin afectar otros)

Contras

Frágil: si A tarda más de esperado, B inicia con datos incompletos
Ineficiente: B espera aunque A terminó en 10 min
No hay verificación real de que A completó

Cuándo usar

Workflows con duración predecible y estable
No crítico que B inicie inmediatamente después de A
Bajo volumen / sin urgencia

Estrategia 2: Execute Workflow al final (chain)

Workflow A termina llamando explícitamente a Workflow B.

Workflow A:
[Schedule 6am] → [procesamiento] → [Execute Workflow: B]

Workflow B:
[Execute Workflow Trigger] → [procesamiento] → [Execute Workflow: C]

Pros

Garantía: B solo corre después de A
Eficiente: no hay esperas innecesarias
Explícito: la cadena es visible en el código

Contras

Coupling: A "conoce" a B. Si renombras B, A se rompe
Sub-workflows deben estar configurados como callable

Cuándo usar

Workflows que siempre corren en cadena
Duración variable de A
Necesitas garantía de orden

Estrategia 3: Webhook + Schedule (más robusto)

Workflow A al terminar manda un webhook que dispara Workflow B.

Workflow A:
[Schedule 6am] → [procesamiento] → [HTTP POST a webhook de B]

Workflow B:
[Webhook Trigger] → [procesamiento]

Pros

Desacoplado: B no sabe de A directamente
Escalable: múltiples workflows pueden disparar B
Flexible: B puede dispararse desde cualquier lugar que conozca su webhook URL

Contras

Más complejo de configurar
Auth del webhook crítico
Si A falla a mitad, B nunca se dispara (a diferencia de Schedule fixo)

Cuándo usar

Workflows que podrían correr en cadena pero también independientes
Sistemas con múltiples triggers
Setup más serio / productivo

Comparación rápida

Estrategia	Simple	Garantía orden	Acoplamiento	Eficiente
Schedule offset	✅	❌	❌	❌
Execute Workflow	⚠️	✅	⚠️	✅
Webhook + Schedule	❌	✅	✅ desacoplado	✅

Patrón híbrido: Schedule + verification

Una variante de Estrategia 1 más robusta:

Workflow B:
[Schedule 7am]
   │
[Verificar: ¿A terminó OK hoy?] ← lectura de un flag/Sheet
   │
[IF: A completó]
├─ TRUE → procesar
└─ FALSE → [Wait 15 min] → re-verificar (o alertar)

B verifica que A completó antes de procesar. Si A no ha terminado, espera o alerta.

Workflow A debe escribir un flag al terminar (Sheet append, write file, set var compartida).

Caso de uso: pipeline diario

Escenario:

A: Sync de datos desde CRM externo a Sheet local (6:00am, ~30 min)
B: Limpia/normaliza los datos (~tras A)
C: Genera reportes y manda Slack (~tras B)

Implementación con Estrategia 2

Workflow A:
[Schedule 6am]
   │
[Sync con CRM]
   │
[Execute Workflow: B]


Workflow B:
[Execute Workflow Trigger]
   │
[Normalizar datos]
   │
[Execute Workflow: C]


Workflow C:
[Execute Workflow Trigger]
   │
[Generar reportes]
   │
[Slack]

Cadena explícita. Si A tarda 50 min, B inicia a las 6:50am sin problema.

Cuándo dependencia es overkill

A veces tu cadena no requiere ser estricta. Casos:

A y B independientes en datos: pueden correr a la vez
B puede leer datos viejos de A si están disponibles: falla soft
Workflows que tocan distintos sistemas sin overlap

Si no hay dependencia real, mantén workflows independientes con Schedule independientes. Menos complejidad.

Trampas comunes

Trampa 1: Asumir tiempo fijo (Estrategia 1)

Qué pasa: Configuras A 6am, B 7am asumiendo A tarda 30 min. Un día A tarda 70 min por volumen alto. B procesa datos parciales.

Cómo evitar: Verificar empíricamente la duración. Si varía, usar Estrategia 2 o 3.

Trampa 2: Chain demasiado larga

Qué pasa: A → B → C → D → E → F en cadena. Si falla en B, no llegan a C-F. Difícil de debuggear.

Cómo evitar:

Limitar chains a 3-4 workflows
Considerar consolidar en menos workflows si todos hacen parte del mismo pipeline lógico

Trampa 3: Loop accidental (A → B → A)

Qué pasa: Configuras A llama B, después accidentalmente B llama A. Loop infinito.

Cómo evitar: Diseñar la cadena con dirección clara antes de implementar. Revisar.

Trampa 4: B asume A pero A no escribe flag

Qué pasa: B verifica que A completó leyendo un flag. A nunca escribe el flag al final. B siempre cree que A falló.

Cómo evitar: En A, asegurar que el flag se escribe al final (después del procesamiento exitoso), no al inicio.

Ejercicio: diseñar pipeline

Caso:

A: descargar nuevos pedidos de Shopify (cada 4 horas)
B: para cada pedido, generar factura (debería iniciar después de A)
C: enviar emails de facturación (después de B)

¿Qué estrategia usarías? ¿Por qué?

Solución sugerida

Estrategia 2 (Execute Workflow) o Estrategia 3 (Webhook).

Cadena clara A → B → C
Duración variable (depende de cuántos pedidos)
Necesita garantía de orden (factura antes que email)

Estrategia 1 (Schedule offset) sería frágil — pedidos picos llevarían B a iniciar con datos incompletos.

Resumen

3 estrategias de scheduling dependiente: offset, Execute Workflow, Webhook
Schedule offset simple pero frágil
Execute Workflow garantiza orden con acoplamiento ligero
Webhook más robusto y desacoplado pero más complejo
Patrón híbrido: Schedule + verification para casos intermedios
4 trampas: tiempo fijo asumido, chain larga, loop, flag mal escrito

Lo que sigue: DST y edge cases — los detalles que importan en producción.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorBusiness Days y Calendarios Fiscales Siguiente →DST y Edge Cases