Elegir la herramienta: Workflow, Queue o cron

Cron, Queues y Workflows comparten una superficie engañosa: los tres sirven para “ejecutar código más tarde”. Elegir por ese rasgo —cualquiera vale, total, todos difieren el trabajo— es el error de principiante que produce arquitecturas que se pudren. Cada herramienta desacopla por un eje distinto: el cron responde a “cuándo”, la Queue a “cuántos y en qué orden de llegada”, el Workflow a “qué secuencia, con qué estado, sobreviviendo a qué fallos”. El criterio no está en la herramienta, sino en la forma del problema; y el ingeniero maduro, además de elegir bien, las compone en capas en vez de forzar a una a hacer el papel de otra.

Tres ejes: tiempo, mensaje, proceso

La confusión nace de lo que comparten; la claridad, de lo que los separa. Un cron desacopla por el tiempo: se dispara según un calendario, ajeno a cualquier petición o mensaje. Su manejador scheduled se enciende, hace su tarea y termina; no guarda estado por elemento ni orquesta nada largo. Es un despertador, no un director de orquesta.

Una Queue desacopla por la carga: un productor deja mensajes y un consumidor los recoge en lotes a su propio ritmo, con reintentos por mensaje, contrapresión cuando el consumidor va lento, y una cola de mensajes muertos para los que envenenan el proceso. Cada mensaje es una unidad independiente; no existe la noción de “paso tres del viaje de este mensaje”.

Un Workflow desacopla por la duración del proceso: una instancia es un único proceso largo, ordenado y con estado, que puede dormir días y reintentar por paso arrastrando su estado hacia adelante. No va de muchas unidades independientes, sino de una unidad que debe avanzar con fiabilidad a lo largo del tiempo.

El criterio de decisión

La decisión se reduce a tres preguntas, formuladas en orden. ¿El disparador es un reloj, algo que debe ocurrir de forma periódica? Entonces es un cron. ¿Es un caudal de unidades independientes que debes absorber a escala sin perder ninguna, desacoplando a quien las produce de quien las procesa? Entonces es una Queue. ¿Es un proceso único que debe avanzar por pasos ordenados, conservar estado, esperar y sobrevivir a fallos? Entonces es un Workflow.

Las señales de que elegiste mal son inconfundibles una vez que sabes mirarlas. Un cron que lee una tabla en cada disparo para averiguar “por dónde va cada cosa” es un Workflow reimplementado a mano. Un consumidor de Queue con un switch gigante sobre un campo de estado es un Workflow reimplementado a mano. Y un Workflow que se lanza por cada mensaje trivial de disparar y olvidar es una Queue sobredimensionada. La herramienta correcta hace que el código deje de pelear consigo mismo.

No compiten, se componen

Lejos de ser rivales, las tres son capas de una misma tubería. Un cron se dispara cada noche y reparte el trabajo encolando un mensaje por cuenta. La Queue absorbe ese pico y entrega cada mensaje a un consumidor con contrapresión y reintentos. Y el consumidor, para los mensajes que exigen un viaje largo, fiable y de varios pasos, arranca una instancia de Workflow por elemento.

export default {
  // 1. cron: dirigido por el tiempo. Se dispara y reparte trabajo
  async scheduled(event: ScheduledEvent, env: Env) {
    const cuentas = await listarCuentasActivas(env);
    await env.COLA.sendBatch(cuentas.map((c) => ({ body: c.id })));
  },

  // 2. Queue: dirigido por el mensaje. Absorbe carga con reintentos
  async queue(batch: MessageBatch<string>, env: Env) {
    for (const msg of batch.messages) {
      // 3. Workflow: dirigido por el proceso. Uno durable por elemento
      await env.FACTURAR.create({ params: { cuentaId: msg.body } });
      msg.ack();
    }
  },
};

flowchart LR
CRON[cron cada noche] -->|encola un mensaje por cuenta| Q[Queue absorbe carga]
Q -->|entrega con reintentos| CON[Consumidor]
CON -->|lanza uno por elemento| WF[Workflow durable]
WF --> OK[proceso completado]
style CRON fill:#cba6f7,color:#11111b
style Q fill:#89b4fa,color:#11111b
style WF fill:#a6e3a1,color:#11111b