Jobs de mídia assíncronos: combinando webhooks, polling e máquinas de estado

Projete um ciclo de vida de jobs recuperável que evita cobrança duplicada, callbacks perdidos e trabalhos permanentemente pendentes.

Conclusão principalWebhooks fornecem notificação de baixa latência, polling garante convergência e uma máquina de estado evita conflitos entre eles.

Jobs longos não devem fingir ser síncronos

A geração de vídeo pode passar por enfileiramento, execução, moderação, upload e transcodificação. Manter uma requisição HTTP aberta convida timeouts de gateway e torna o comportamento de refresh pouco claro. Uma API mais limpa retorna um request_id e estado pending imediatamente, depois avança por meio de consultas ou callbacks.

Defina uma máquina de estado unidirecional

Use um conjunto finito como pending, running, succeeded, failed e canceled, com transições permitidas explícitas. Um estado terminal não pode ser sobrescrito por um evento antigo; eventos duplicados são seguros; e toda transição retém sua origem, horário e ID do job do provedor.

Envie com uma chave de idempotência para que retentativas de rede não criem outro job.
Verifique assinaturas e timestamps de webhooks, e retenha um resumo do evento.
Deduplique antes de atualizar o estado e, em seguida, dispare o trabalho downstream.
Valide tipo de arquivo, tamanho e expiração após baixar o resultado.

Webhooks e polling são complementares

Webhooks sozinhos permanecem vulneráveis a falhas de rede, configuração e do consumidor. Polling frequente sozinho desperdiça quota e aumenta a carga. A ModelRush recomenda webhooks como caminho principal com polling de backoff exponencial para reconciliação. Após a duração esperada, reduza a frequência e entre em alertas ou revisão manual.

Lide com eventos atrasados e duplicados

Eventos distribuídos podem se repetir, chegar fora de ordem ou atrasados. Use uma versão ou escrita condicional para mudanças de estado. Um job succeeded não deve voltar para running porque um callback antigo chegou, e um sucesso duplicado não deve publicar duas vezes.

Teste a confiabilidade injetando falhas: descarte um callback, repita um evento, atrase-o dez minutos e expire uma URL de resultado. O fluxo de trabalho ainda deve convergir para o estado correto.