Сценарий

Фоновые задачи на той же платформе, что и API

Ответ за миллисекунды; длинный хвост — пайплайнам и очереди задач.

Смотреть пайплайны →Альтернатива Trigger.dev

Нагрузка и где ломается

Перегруз потока запроса

Длинные HTTP бьют по таймаутам API-Gateway и бесят пользователей.

Лавина повторных попыток дублирует эффекты без идемпотентности.

Где костыли не спасают

Самодельные очереди болят

У каждого сервиса своя группа обработчиков в Redis — со временем это разъезжается в сопровождении.

Без общей наблюдаемости фона остаётся чёрный ящик.

Как помогает Inquir

Единая поверхность

Функции становятся шагами; платформа ведёт исполнение похоже на синхронные вызовы.

Переиспользуйте секреты и сетевые настройки и для ответов по HTTP, и для фоновых шагов пайплайна.

Что получаете

Паттерны

Веерная постановка

Одно событие — много задач с ясным владельцем.

Компенсация

Откат или эскалация при частичных сбоях.

Ограничение нагрузки

Регулируйте параллелизм под хрупкий приёмник.

Что делать дальше

Как проектировать фоновые задачи на Inquir Compute

Описать полезную нагрузку

Версионируйте схемы, чтобы обновления не ломали уже идущие задачи.

Сделать идемпотентным

Защита записей стабильными ключами.

Наблюдать

Сигналы на отложенные и проблемные сообщения, если платформа это показывает.

Пример кода

Передача в фон

HTTP-хендлер читает JSON из event.body (строка на маршрутах API-Gateway) и может вернуть 202 Accepted.

http.mjs

export async function handler(event) {
  const body = JSON.parse(event.body || '{}');
  await enqueue({ type: 'render_pdf', userId: body.userId });
  return { statusCode: 202, body: JSON.stringify({ accepted: true }) };
}

Когда подходит

Имеет смысл уходить в фон, когда…

Когда это уместно

Работа дольше нескольких секунд
Всплески нагрузки
Внешние API с непредсказуемой задержкой

Когда лучше не трогать

Мгновенные чтения в рамках ваших соглашений по времени ответа

FAQ

Вопросы и ответы

Достижима ли семантика «ровно один раз»?

Ориентируйтесь на идемпотентные хендлеры и ключи дедупликации; «ровно один раз» через сеть и хранилище на практике редко — проектируйте безопасно для как минимум одной доставки.

Когда отвечать HTTP 202?

Когда работа поставлена в очередь и есть идентификатор задачи или запуска — лучше, чем держать соединение до конца длинного экспорта.

Связь с расписаниями и вебхуками?

Пайплайны стартуют от расписания, HTTP, ручного или событийного триггера; вебхук может ответить 200 и поставить задачу в очередь — разные входы, та же схема оркестрации.