Serverless async-задачи без отдельного воркера и очереди
Отложите тяжёлую работу с HTTP-запроса или вебхука в оркестрацию одной строчкой: `global.durable.startNew(name, undefined, payload)`. Без Redis, без BullMQ, без отдельного воркер-сервиса.
Обновлено: 2026-04-20
Кратко
Суть ответа
Serverless async-задачи без отдельного воркера и очереди. `global.durable.startNew(name, undefined, payload)` из любой функции запускает оркестрацию асинхронно. Никакого SDK очереди, никакого воркера.
Когда подходит и когда нет
- Любая работа, которая не должна задерживать ответ пользователю
- Нужны повторы и история без Redis-инфраструктуры
На что обратить внимание
- In-memory очередь теряет задачи при рестарте процесса. Без повторов и Dead Letter неудачные задачи исчезают тихо.
- Внешняя очередь (SQS, RabbitMQ) добавляет latency, стоимость и необходимость управлять инфраструктурой.
Ситуация: нагрузка и где обычно ломается
Почему async-задачи сложнее, чем кажется
Отложить работу за пределы HTTP-запроса традиционно означает: Redis + очередь + воркер. Три компонента, три точки отказа.
SDK очереди в хост-приложении — ещё одна зависимость. При смене языка или фреймворка очередь переезжает вместе с кодом.
Компромиссы
Где ломаются самописные и «лёгкие» очереди: in-memory без персистентности, внешние брокеры и потерянные задачи
In-memory очередь теряет задачи при рестарте процесса. Без повторов и Dead Letter неудачные задачи исчезают тихо.
Внешняя очередь (SQS, RabbitMQ) добавляет latency, стоимость и необходимость управлять инфраструктурой.
Как Inquir помогает в этом сценарии
Как Inquir заменяет связку Redis + воркер: вызов `global.durable.startNew()` из функции и встроенные повторы с историей
`global.durable.startNew(name, undefined, payload)` из любой функции запускает оркестрацию асинхронно. Никакого SDK очереди, никакого воркера.
Повторы, Dead Letter и история — встроены. Функции на Node.js, Python или Go — изолированы и управляют своими зависимостями.
Что вы получаете на платформе
Что нужно для надёжной async-задачи
Триггер без блокировки
`global.durable.startNew()` возвращает управление немедленно; оркестрация работает отдельно.
Повторы
Политика повторов на уровне шага — экспоненциальная выдержка без дополнительного кода.
История
Каждый прогон — запись в консоли с логами и статусом шагов.
Изоляция
Пайплайн и его функции в отдельных контейнерах; зависимости не влияют на основное приложение.
Что сделать дальше, по шагам
Как поставить задачу в очередь через Inquir
Принять запрос
HTTP-функция или вебхук-обработчик проверяет входные данные.
Вызвать global.durable.startNew()
Одна строка — payload уходит в оркестрацию; функция сразу возвращает ответ клиенту.
Шаги делают работу
Пайплайн выполняет шаги с повторами и историей без HTTP-ограничений.
Пример кода
Async job from webhook trigger
Webhook verifies and acks in under 1 second; slow work runs in a separate pipeline step with full retry and observability.
export async function handler(event) { // Verify signature first — see /serverless-webhook-processor for full pattern const payload = JSON.parse(event.body || '{}'); await db.upsertEvent(payload.id, payload.type); // idempotency key // Trigger async job — runs outside this request window await global.durable.startNew('process-event', undefined, { eventId: payload.id, type: payload.type }); return { statusCode: 200, body: 'accepted' }; }
Когда подходит и когда нет
Когда фоновые async-задачи на Inquir уместнее отдельной очереди и воркер-сервиса
Когда это уместно
- Любая работа, которая не должна задерживать ответ пользователю
- Нужны повторы и история без Redis-инфраструктуры
Когда лучше не трогать
- Результат нужен синхронно в том же HTTP-запросе
Вопросы и ответы
Вопросы и ответы
Чем отличается от BullMQ?
BullMQ требует Redis + воркер. В Inquir `global.durable.startNew()` — вся очередная логика без внешней инфраструктуры.
Можно вызвать пайплайн из Python?
Да. HTTP-запрос к URL пайплайна — стандартный REST-вызов из любого языка.