Volver al blog
Ingeniería
Publicado el 2 ago 2026
7 min de lectura
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.
