Flujos de trabajo durables: sobrevivir al fallo
La automatización real corre en un mundo que falla — las redes se caen, las API agotan su tiempo, las máquinas se reinician. Los motores de flujo de trabajo durables están construidos para que un trabajo pueda caerse y retomar exactamente donde lo dejó.
La automatización real corre en un mundo que falla. Las redes se caen, las API agotan su tiempo, las máquinas se reinician. La pregunta no es si tu trabajo se cae — es si puede volver a levantarse donde cayó.
Imagina un trabajo de cuatro pasos: cobrar la tarjeta, reservar el stock, contratar al mensajero, enviar el correo. Ahora imagina que la API del mensajero agota su tiempo en el paso tres. Un script ingenuo no tiene memoria de hasta dónde llegó — así que cuando lo vuelves a ejecutar, empieza desde el paso uno y cobra la tarjeta de nuevo. El fallo no fue el tiempo agotado; fue que la recuperación rehízo trabajo que nunca debería repetirse. En la automatización, una caída a mitad de camino no es un inconveniente. Es un cobro doble esperando a ocurrir.
Un motor de flujo de trabajo durable elimina exactamente este peligro. Después de que cada paso se completa, persiste el resultado — de forma durable, fuera del proceso en ejecución. Si el proceso muere, vuelve a leer lo que ya está hecho y reanuda en el siguiente paso sin terminar. Por debajo, cada paso vive en una pequeña máquina de estados, y esa máquina es lo que hace posible “ejecutar exactamente una vez”:
Idempotencia: la regla que hace seguros los reintentos
Hay una trampa que el diagrama oculta. Un reintento solo permanece seguro si repetir un paso no tiene ningún efecto extra — y “cobrar la tarjeta” vaya que lo tiene. La solución es una clave de idempotencia: cada paso con efectos secundarios lleva un token único atado al flujo de trabajo, y el sistema de destino promete que dos llamadas con el mismo token cobran una sola vez. Con ella, el motor puede reintentar libremente; sin ella, cada reintento es un cobro nuevo. La idempotencia es lo que permite que “ejecútalo de nuevo” sea una instrucción segura en lugar de una peligrosa.
Podrías intentar construir todo esto a mano — una columna de estado, un montón de comprobaciones de “¿ya hice esto?”, lógica de reintentos por todas partes — y es donde vive una proporción asombrosa de los errores de producción. Por eso los motores durables (Temporal, Inngest, Trigger.dev) existen como su propia categoría: hacen que “reanudar exactamente donde lo dejaste” sea lo predeterminado, no algo que atornillas y luego rezas. El curso de oficio señaló lo mismo — prefiere la parte aburrida y probada para el problema ya resuelto.
Dónde se tuerce
Suponer que el camino feliz es toda la historia. Un script que funciona en la demo, donde nada falla, se siente terminado — y luego se encuentra con el mundo real, donde la tercera llamada agota su tiempo a las 2 de la madrugada y el reintento en silencio le factura a un cliente dos veces. Construye para la interrupción que no ves venir: en la automatización no es un caso límite, es un martes cualquiera.
Ponlo en práctica
Toma una automatización de varios pasos de la que dependes y hazle una pregunta a cada paso: si el proceso muriera justo después de este, ¿qué pasa cuando se ejecuta de nuevo? Cualquier lugar donde la respuesta sea “rehace algo que no debería” — un cobro, un correo, un pedido — es un paso que necesita durabilidad y una clave de idempotencia. Esa lista es el argumento a favor de un motor durable, escrito con los riesgos de tu propio sistema.
Basado en el modelo de ejecución durable detrás de motores como Temporal, Inngest y Trigger.dev.