Фоновые задачи на той же платформе, что и API
Ответ за миллисекунды; длинный хвост — пайплайнам и очереди задач.
Обновлено: 2026-04-20
Кратко
Суть ответа
Фоновые задачи на той же платформе, что и API. Функции становятся шагами; платформа ведёт исполнение похоже на синхронные вызовы.
Когда подходит и когда нет
- Работа дольше нескольких секунд
- Всплески нагрузки
- Внешние API с непредсказуемой задержкой
На что обратить внимание
- У каждого сервиса своя группа обработчиков в Redis — со временем это разъезжается в сопровождении.
- Без общей наблюдаемости фона остаётся чёрный ящик.
Ситуация: нагрузка и где обычно ломается
Почему держать долгую работу внутри одного HTTP-запроса ломает таймауты шлюза и опыт пользователя
Длинные HTTP бьют по таймаутам API-Gateway и бесят пользователей.
Лавина повторных попыток дублирует эффекты без идемпотентности.
Когда упрощённых рецептов мало
Почему разрозненные самописные очереди (например, на Redis) усложняют сопровождение фоновой обработки
У каждого сервиса своя группа обработчиков в Redis — со временем это разъезжается в сопровождении.
Без общей наблюдаемости фона остаётся чёрный ящик.
Как Inquir помогает в этом сценарии
Как Inquir объединяет HTTP-функции и шаги пайплайнов с общими секретами и журналами выполнения
Функции становятся шагами; платформа ведёт исполнение похоже на синхронные вызовы.
Переиспользуйте секреты и сетевые настройки и для ответов по HTTP, и для фоновых шагов пайплайна.
Что вы получаете на платформе
Типовые паттерны фоновых задач на пайплайнах Inquir
Веерная постановка
Одно событие — много задач с ясным владельцем.
Компенсация
Откат или эскалация при частичных сбоях.
Ограничение нагрузки
Регулируйте параллелизм под хрупкий приёмник.
Что сделать дальше, по шагам
Как проектировать фоновые задачи на Inquir Compute
Описать полезную нагрузку
Версионируйте схемы, чтобы обновления не ломали уже идущие задачи.
Сделать идемпотентным
Защита записей стабильными ключами.
Наблюдать
Сигналы на отложенные и проблемные сообщения, если платформа это показывает.
Пример кода
Пример: ответ по HTTP сразу и продолжение тяжёлой работы во фоновом пайплайне
HTTP-хендлер возвращает 202 немедленно, не удерживая соединение. Хендлер задачи подхватывает работу с теми же секретами и наблюдаемостью.
export async function handler(event) { const { reportId, userId } = JSON.parse(event.body || '{}'); if (!reportId) return { statusCode: 400, body: JSON.stringify({ error: 'reportId required' }) }; // Enqueue the slow export job — returns immediately const { instanceId: jobId } = await global.durable.startNew('export-report', undefined, { reportId, userId }); // Client polls GET /export-status/:jobId or receives a webhook when done return { statusCode: 202, body: JSON.stringify({ jobId }) }; }
export async function handler(event) { const { reportId, userId } = event.payload; // Idempotency key — safe to retry const existing = await db.exports.findByReportAndUser(reportId, userId); if (existing?.status === 'done') return { url: existing.url }; const rows = await buildReport(reportId); const url = await storage.upload(rows, { key: `reports/${reportId}.csv` }); await db.exports.upsert({ reportId, userId, url, status: 'done' }); await notify(userId, { url }); return { url }; }
Когда подходит и когда нет
Когда имеет смысл уводить работу из синхронного HTTP в фон или пайплайн
Когда это уместно
- Работа дольше нескольких секунд
- Всплески нагрузки
- Внешние API с непредсказуемой задержкой
Когда лучше не трогать
- Мгновенные чтения в рамках ваших соглашений по времени ответа
Вопросы и ответы
Вопросы и ответы
Достижима ли семантика «ровно один раз»?
Ориентируйтесь на идемпотентные хендлеры и ключи дедупликации; «ровно один раз» через сеть и хранилище на практике редко — проектируйте безопасно для как минимум одной доставки.
Когда отвечать HTTP 202?
Когда работа поставлена в очередь и есть идентификатор задачи или запуска — лучше, чем держать соединение до конца длинного экспорта.
Связь с расписаниями и вебхуками?
Пайплайны стартуют от расписания, HTTP, ручного или событийного триггера; вебхук может ответить 200 и поставить задачу в очередь — разные входы, та же схема оркестрации.