starter.wiki

Infrastructure

Background Jobs

Choose how asynchronous work executes and recovers by task duration, durability, workflow state, worker ownership, and failure semantics.

Recommendation

Choose the execution and recovery model before the job library.

Managed task workers, durable event functions, workflow orchestration, and application-owned Redis workers solve different reliability and ownership problems.12

For: Application teams moving slow, retryable, scheduled, or failure-sensitive work outside a request

Main trade-off

Delegating execution and durability reduces worker plumbing while increasing platform-specific programming, limits, billing, and migration coupling.12

Four background execution models

The routes differ in who runs workers, where durable state lives, and how much workflow behavior the platform owns.

  1. Work lifetime and state

    Define duration, steps, waits, human pauses, signals, compensation, cancellation, and workflow history.3

  2. Delivery and recovery

    Set retry, timeout, duplicate, idempotency, dead-letter, backoff, replay, and partial-failure behavior.34

  3. Execution ownership

    Choose who deploys, scales, observes, secures, and recovers workers and durable control-plane state.2

  4. Runtime and economics

    Verify language/runtime fit, concurrency, limits, hosting boundary, compute billing, retention, and operational cost.12

Execution routes

Use the simplest route whose recovery model matches the consequences of failure.

A TypeScript team wants managed task workers

Evaluate Trigger.dev.

Managed compute, code-defined tasks, retries, waits, schedules, and run history can remove worker plumbing.

Verify: Validate current runtime, limits, qualitative plan boundaries, deployment model, and platform coupling.12

Events and durable steps fit application execution

Evaluate Inngest.

Event functions and managed step state can add durable coordination while code remains in application endpoints or connected workers.

Verify: Hosting timeouts, execution ownership, event and step limits, or a need for fully managed workers can change the route.12

Long-lived business workflows require explicit durability

Evaluate Temporal.

Workflow history, activities, timers, signals, and recovery fit failure-sensitive multi-service processes.

Verify: Simple short-lived jobs rarely justify the programming, worker, determinism, versioning, and operating model.123

The team wants direct library and worker control

Evaluate BullMQ.

A Node.js library plus Redis provides an application-owned route with explicit job and worker behavior.

Verify: The team must own Redis durability, workers, scaling, retries, monitoring, backup, and incident recovery.1245

Boundary: Message Queues retains and delivers messages but does not execute application work. Cron & Scheduled Jobs owns time-based invocation. Neither removes job idempotency or recovery design.

What durability means

Retry support alone does not make the routes equivalent; durable state, execution ownership, and recovery obligations differ.

Worker ownership
Managed workers, application endpoints, connected workers, and self-operated workers transfer different responsibilities.45
Durable state
Task runs, event steps, workflow history, and Redis job state support different recovery semantics.3
Programming model
Tasks, events, durable workflows, and queues shape code, testing, versioning, and failure handling.12
Operations
Concurrency, scaling, observability, retention, incidents, and replay remain part of the chosen system.45

Official resources

Use the primary documentation to verify runtime behavior, operating limits, service boundaries, and current commercial terms.

DocumentationBullMQ introduction

Starter stacks

Sources

Official documentation supporting the routes and decision boundaries on this page.

  1. 1
    Trigger.dev task overview

    Trigger.dev · Accessed Official

  2. 2
    Inngest documentation

    Inngest · Accessed Official

  3. 3
    Temporal documentation

    Temporal · Accessed Official

  4. 4
    BullMQ introduction

    BullMQ · Accessed Official

  5. 5
    BullMQ production guidance

    BullMQ · Accessed Official