Trabajos de medios asíncronos: combinación de webhooks, polling y máquinas de estados

Diseña un ciclo de vida de trabajos recuperable que evita facturación duplicada, callbacks perdidos y trabajos pendientes permanentemente.

Conclusión principalLos webhooks proporcionan notificación de baja latencia, el polling garantiza la convergencia y una máquina de estados evita conflictos entre ellos.

Los trabajos largos no deben fingir ser síncronos

La generación de vídeo puede pasar por puesta en cola, ejecución, moderación, carga y transcodificación. Mantener una solicitud HTTP abierta invita a tiempos de espera de puerta de enlace y hace que el comportamiento de actualización sea poco claro. Una API más limpia devuelve un request_id y un estado pendiente inmediatamente, y luego avanza mediante consultas o callbacks.

Define una máquina de estados unidireccional

Utiliza un conjunto finito como pending, running, succeeded, failed y canceled, con transiciones permitidas explícitas. Un estado terminal no puede sobrescribirse con un evento anterior; los eventos duplicados son seguros; y cada transición conserva su origen, hora e ID de trabajo del proveedor.

Envía con una clave de idempotencia para que los reintentos de red no creen otro trabajo.
Verifica las firmas y marcas de tiempo de los webhooks, y conserva un resumen del evento.
Deduplica antes de actualizar el estado y luego activa el trabajo posterior.
Valida el tipo de archivo, el tamaño y la caducidad después de descargar el resultado.

Los webhooks y el polling son complementarios

Los webhooks solos siguen siendo vulnerables a fallos de red, configuración y del consumidor. El polling frecuente solo desperdicia cuota y aumenta la carga. ModelRush recomienda los webhooks como vía principal con polling de retroceso exponencial para la reconciliación. Después de la duración esperada, reduce la frecuencia y entra en alertas o revisión manual.

Gestiona eventos tardíos y duplicados

Los eventos distribuidos pueden repetirse, llegar fuera de orden o con retraso. Utiliza una versión o escritura condicional para los cambios de estado. Un trabajo succeeded no debe volver a running porque llegó un callback antiguo, y un éxito duplicado no debe publicarse dos veces.

Prueba la fiabilidad inyectando fallos: elimina un callback, repite un evento, retrásalo diez minutos y caduca una URL de resultado. El flujo de trabajo debe seguir convergiendo al estado correcto.