Serverless job queue without Redis, SQS, or a worker fleet
Enqueue durable background work from HTTP handlers, webhooks, or cron. Inquir pipelines give you job-queue semantics—enqueue, retries, execution history, and step-level isolation—without provisioning Redis, SQS, RabbitMQ, or a persistent worker process.
Last updated: 2026-06-23
Answer first
Direct answer
Serverless job queue without Redis, SQS, or a worker fleet. Inquir treats background work as pipeline invocations: call global.durable.startNew(name, undefined, payload) from any function and the platform schedules delivery, retries, and execution records.
When it fits
- You need enqueue + retry + history without operating Redis or SQS
- Background jobs should share secrets and logs with your HTTP API surface
Tradeoffs
- In-memory queues inside your API process lose jobs on restart and cannot scale horizontally without duplicate delivery bugs.
- Calling cloud queue APIs from every handler spreads credentials, retry logic, and idempotency keys across the codebase—each team reinvents the same boilerplate.
Workload and what breaks
What a production job queue actually costs
- Queue backend: Redis, SQS, or RabbitMQ—provisioned, monitored, and on the critical path for every job
- Worker fleet: persistent processes that consume the queue, scale with load, and drain safely on deploy
- Retry and dead-letter policy: exponential backoff, max attempts, and a place failed jobs land for inspection
- Observability: a dashboard or CLI to see queue depth, stalled jobs, and failure reasons
Job queues solve real problems: decouple producers from consumers, absorb traffic spikes, and retry flaky work. But the queue itself becomes infrastructure you operate before the first business job runs.
Trade-offs
Why DIY queues and in-process hacks break
In-memory queues inside your API process lose jobs on restart and cannot scale horizontally without duplicate delivery bugs.
Calling cloud queue APIs from every handler spreads credentials, retry logic, and idempotency keys across the codebase—each team reinvents the same boilerplate.
How Inquir helps
Job-queue semantics as managed serverless pipelines
Inquir treats background work as pipeline invocations: call global.durable.startNew(name, undefined, payload) from any function and the platform schedules delivery, retries, and execution records.
Each job runs in an isolated serverless container with workspace secrets and the same observability as HTTP routes—no Redis connection string, no worker systemd unit, no queue drain script on deploy.
What you get
Serverless job queue patterns on Inquir
Enqueue from any trigger
HTTP 202, verified webhook, cron schedule, or another pipeline step—one enqueue API regardless of entry point.
Retries with backoff
Configure retry count and delay per pipeline step—equivalent to queue job options without a separate DLQ service.
Execution history
Every enqueue creates a run record: input payload, step outputs, duration, retry count, and failure reason in the console.
Fan-out and chaining
One job enqueues N child pipelines or chains steps with dependsOn—queue fan-out without a second queue product.
What to do next
How to run a serverless job queue on Inquir
Write the job handler
Export a function that reads event.payload and returns structured output—the consumer side of the queue.
Enqueue from the producer
From an HTTP handler or webhook, call global.durable.startNew(jobName, undefined, payload) and return immediately.
Configure retries and monitor
Set retry policy on the pipeline step; watch execution history for stalled or failing jobs.
Code example
Enqueue a job without Redis or SQS
The producer validates input and enqueues; the job handler runs outside the HTTP window with platform-managed retries.
export async function handler(event) { const { exportId, format } = JSON.parse(event.body || '{}'); if (!exportId) return { statusCode: 400, body: JSON.stringify({ error: 'exportId required' }) }; const { instanceId: jobId } = await global.durable.startNew('run-export', undefined, { exportId, format: format ?? 'csv' }); return { statusCode: 202, body: JSON.stringify({ jobId, status: 'queued' }) }; }
export async function handler(event) { const { exportId, format } = event.payload ?? {}; const rows = await fetchExportRows(exportId); const fileUrl = await writeExport(rows, format); await notifyExportReady(exportId, fileUrl); return { exportId, fileUrl, rowCount: rows.length }; }
When it fits
When a managed serverless job queue fits
When this works
- You need enqueue + retry + history without operating Redis or SQS
- Background jobs should share secrets and logs with your HTTP API surface
When to skip it
- Sub-millisecond queue latency with strict FIFO ordering across millions of jobs per second—use a dedicated message broker
FAQ
FAQ
Is this the same as AWS SQS?
SQS is a managed message queue you integrate via SDK. Inquir pipelines give similar enqueue-and-forget semantics tied to your function catalog—no separate queue service, IAM policies, or worker consumers to deploy.
How do failed jobs behave?
Pipeline steps retry according to configured policy. Exhausted retries mark the run failed with logs—inspect in execution history without configuring a separate dead-letter queue.
Can I enqueue from Python or Go handlers?
Yes. global.durable.startNew() works from Node.js handlers; other runtimes can POST to the pipeline trigger URL with the same payload shape.