Приоритеты очереди video API: как не потерять задачи и бюджет

Определите приоритет как политику

Слово «срочно» не является техническим полем. Опишите короткую политику: например, интерактивный предпросмотр, обычная пользовательская задача и отложенный пакетный рендер. Каждому классу назначьте владельца, допустимый тип входа, ограничение незавершённых задач и правило показа статуса. Не связывайте высокий класс с ролью из запроса браузера: сервер определяет его по тарифу, продуктовой функции и проверенной авторизации.

Приоритет не обещает фиксированное время готовности. В очереди бывают 429, 5xx, отмена, длинная обработка и меняющаяся доступность модели. Пользователю лучше показать «в очереди, позиция не гарантируется» и время последнего обновления, чем выдуманную минуту. Если ваш продукт меняет стоимость или порядок обслуживания, оформите это прозрачно в собственных правилах. RussiaAPI не следует представлять как официального производителя модели или как источник гарантированной скорости.

Храните явные состояния задачи

Задача начинается в accepted после проверки пользователя, прав на исходный материал, лимита и бюджета. Затем worker переводит её в queued, submitted, checking, ready, failed или cancelled. У перехода есть время, причина и внутренний actor. Такой журнал позволяет не принять повторный клик за новую работу и не выдать готовый ролик без проверки владельца.

Не помечайте задачу ready только по тому, что внешний callback пришёл в сеть. Сначала проверьте документированную подпись и event ID, затем сопоставьте задачу и текущий переход. Подробности для callback собраны в проверке подписи webhook. Если callback недоступен по контракту, используйте ограниченный polling; выбор способа не меняет необходимости авторизовать чтение статуса.

Сделайте справедливость измеримой

Простая очередь «самый высокий приоритет всегда первый» может навсегда оставить обычные задачи в конце. Добавьте aging: чем дольше задача ждёт, тем больше её эффективный балл до заранее заданного потолка. Одновременно ограничивайте число активных и ожидающих задач на tenant. Это не гарантирует мгновенный запуск, но мешает одному интегратору занять весь пул и позволяет измерить максимальное ожидание по каждому классу.

Рассчитывайте балл на сервере из проверенного класса и времени постановки. Не используйте client timestamp, отрицательный priority или произвольный URL callback из тела запроса. Сохраните исходный policy version вместе с задачей: при изменении правил не нужно переписывать историю, а оператор понимает, почему две задачи были поставлены в разном порядке. Общее ограничение concurrency описано в материале о параллельных запросах.

Планировщик не должен раскрывать секреты

Этот упрощённый пример для Node.js 18+ выбирает следующую работу из уже проверенной внутренней таблицы. Он не утверждает, что endpoint /v1/video/generations доступен всем моделям: сверяйте тело запроса и ответ с актуальным контрактом. Внешний ключ остаётся в environment worker, а клиент получает только свой operation ID. Реальная база должна блокировать выбранную строку транзакционно, чтобы два worker не взяли одну задачу.

export async function dispatchNextVideo() {
  const task = await lockBestQueuedTask(); // DB transaction + FOR UPDATE SKIP LOCKED
  if (!task) return;
  if (await activeCount(task.tenantId) >= task.tenantLimit) return await releaseForLater(task.id);
  await markSubmitted(task.id);
  try {
    const response = await fetch('https://russiaapi.com/v1/video/generations', {
      method: 'POST',
      headers: { authorization: `Bearer ${process.env.RUSSIAAPI_API_KEY}`, 'content-type': 'application/json' },
      body: JSON.stringify({ model: task.model, prompt: task.prompt }),
      signal: AbortSignal.timeout(15_000)
    });
    if (!response.ok) return await markRetryPolicy(task.id, response.status);
    const data = await response.json();
    await saveProviderTask(task.id, data.id); // validate the current response contract
  } catch { await markChecking(task.id); }
}

// SQL ordering example: base_priority + least(wait_minutes, 60) DESC, created_at ASC

До отправки worker повторно проверяет лимит tenant и срок задачи. При неоднозначном timeout он не создаёт новую строку, а ставит текущую в checking и выполняет разрешённую сверку. Для защиты от двойных кликов применяйте внутренний ключ из руководства по idempotency. Очередь не должна логировать исходные видео, API key, подписи callback или временные URL результата.

Отмена, дедлайн и сбой модели

Отмена зависит от момента. Пока задача queued, можно атомарно снять её с очереди и освободить внутренний резерв. После submitted отмена может быть недоступна или иметь иной контракт; не обещайте её без проверки документации. Вместо ложного success покажите состояние «проверяется отмена» и продолжайте авторизованную сверку. У дедлайна должно быть финальное действие: отменить локальное ожидание, отметить задачу для ручной проверки или получить статус по допустимому маршруту.

Не переводите всю очередь на другую модель молча. Fallback меняет качество, цену, права и формат результата, поэтому он должен быть продуктовой policy с контрактным тестом и наблюдаемым флагом. Сценарий безопасного переключения описан в статье о fallback моделей. Если необходимая операция не поддерживается, сообщите об этом пользователю, а не ищите путь обхода ограничений или условий поставщика.

Проверьте очередь до реальной нагрузки

Тестовый набор должен воспроизводить десяток обычных задач, один активный tenant, длительно ожидающую запись, повторный клик, отмену на границе submit и дубликат callback. Проверьте, что aging действительно даёт шанс низкому классу, но не нарушает лимиты. Отдельно измерьте p50 и p95 ожидания по policy version; это показатели вашего приложения, а не обещание RussiaAPI или производителя модели.

Доступ к готовому видео всегда проверяет tenant, состояние и срок выдачи. Временную ссылку не добавляйте в общий лог и не возвращайте по одному task ID без сессии. Практика безопасного хранения и истечения ссылок разобрана в материале о result URL. Приоритеты делают обработку объяснимой, но не заменяют права на материалы, лимиты расходов, обработку персональных данных или применимые требования.