Background jobs and workflows: the agent answers

I’d use **Trigger.dev Cloud**.

It fits this job unusually well: Node/TypeScript tasks, configurable retries and backoff, concurrency-controlled queues, per-run logs/traces, manual replay, and explicit support for Puppeteer/Chrome-based PDF generation. It also supports parent/child tasks and durable waits when your workflows become multi-step. [Tasks and retries](https://trigger.dev/docs/tasks/overview), [Puppeteer support](https://trigger.dev/docs/config/extensions/puppeteer), [run inspection and replay](https://trigger.dev/docs/runs), [workflow waits](https://trigger.dev/docs/wait).

The request flow should become:

1. Create a `report_job` row with status `queued`.
2. Trigger the task using the report ID as an idempotency key.
3. Immediately return `202 Accepted` with that ID.
4. The worker generates the PDF and uploads it to object storage.
5. Update the row to `completed` with the object key—or `failed` with a sanitized error code/message.
6. Let the frontend poll `/reports/:id`, subscribe to Trigger.dev’s realtime status, or receive a notification.

Keep the database as the product-facing source of truth. Trigger.dev’s dashboard is excellent for developers, but users and support staff should be able to see status without access to your infrastructure.

A few implementation details matter:

- Make generation idempotent. Retries must overwrite the same object key or safely detect an already-produced PDF.
- Retry transient failures—browser crashes, storage timeouts, temporary API errors—but abort immediately on invalid report input.
- Store inputs by reference rather than placing sensitive or very large datasets in the task payload.
- Set a sensible `maxDuration`, concurrency limit, and memory size. Browser rendering can spike RAM.
- Return PDFs through short-lived signed URLs rather than making the bucket public.
- Record attempts, timestamps, and a correlation/run ID in `report_jobs`.

What I also considered:

- **Inngest:** The closest alternative and arguably better if event-driven, checkpointed multi-step workflows become the dominant requirement. Each `step.run()` is persisted and retried independently, and its UI exposes traces and failure metrics. I’d choose it over Trigger.dev if your future roadmap is mostly orchestration rather than heavyweight browser jobs. [Durable steps](https://www.inngest.com/docs/learn/inngest-steps), [error handling](https://www.inngest.com/docs/guides/error-handling), [observability](https://www.inngest.com/docs/platform/monitor/observability-metrics).

- **Temporal Cloud:** The strongest choice for complex, business-critical workflows lasting days or months, with signals, compensation, versioning, and very strong execution guarantees. It is more conceptual and operational machinery than a 40-second PDF job warrants. I’d revisit it if workflows become core domain infrastructure rather than supporting jobs.

- **BullMQ + Redis:** Good, inexpensive, and familiar for Node. It handles retries and queues well, but you own Redis, worker deployment, dashboards, alerting, cleanup, and eventually workflow semantics. Sensible when minimizing vendor spend matters more than reducing operational work.

- **Cloud-native queue + container worker:** For example, SQS plus ECS/Fargate on AWS, or the equivalents on another cloud. This gives maximum portability and control and is a good option if your organization already has the infrastructure patterns. You must assemble retries, dead-letter queues, run history, observability, workflow orchestration, and deployment yourself.

- **AWS Step Functions or another cloud workflow product:** Capable, especially when everything already lives in that cloud, but the workflow definition and local development experience are less natural than ordinary TypeScript for a small Node team.

My practical decision rule: start with **Trigger.dev** for this workload; choose **Inngest** if durable event orchestration is already the larger goal; choose **Temporal** only when workflow correctness becomes important enough to justify a platform-level commitment.

I’d use **Trigger.dev Cloud**.

It fits this case unusually well: Node/TypeScript jobs that take tens of seconds, automatic retries, a useful failure dashboard, and a natural path toward multi-step workflows—without operating Redis, workers, or a workflow cluster.

The request flow becomes:

1. Create a `report` row with status `queued`.
2. Trigger `generate-report` using the report ID as an idempotency key.
3. Immediately return `202 Accepted` with the report ID.
4. The task renders the PDF, stores it in object storage, and updates the row to `completed` or `failed`.
5. The UI polls your report-status endpoint or subscribes for updates.

Trigger.dev retries thrown errors with configurable backoff; each run exposes its attempts, errors, status, payload, and output. Its dashboard also includes logs and traces, and failed runs can be grouped and replayed. Later, you can add child tasks, waits, parallel work, and durable multi-step orchestration without changing infrastructure. [Tasks and retries](https://trigger.dev/docs/tasks/overview), [runs and attempts](https://trigger.dev/docs/runs), [logging and tracing](https://trigger.dev/docs/logging), [durable waits](https://trigger.dev/docs/wait).

One architectural point matters regardless of service: make PDF generation idempotent. Use a stable report ID/object key, and make the final database update conditional. All practical job systems can deliver or execute work more than once around crashes.

What else I considered:

| Option | Verdict |
|---|---|
| **Inngest** | Very close second. Its checkpointed `step.run()` model and per-step retry/trace UI are excellent for event-driven workflows. I’d choose it over Trigger.dev if your future system is primarily business events and functions running on your existing compute. [Steps](https://www.inngest.com/docs/learn/inngest-steps), [retries](https://www.inngest.com/docs/guides/error-handling), [traces](https://www.inngest.com/docs/platform/monitor/traces). |
| **Temporal Cloud** | Best for genuinely complex, long-lived, business-critical workflows with signals, compensation, and strong durability requirements. For one 40-second PDF job, its worker/runtime concepts and operational learning curve are more than I’d introduce today. [Temporal documentation](https://docs.temporal.io/). |
| **BullMQ + Redis** | Good if you want maximum control and already operate Redis. Mature retry and flow primitives, but you own workers, scaling, Redis durability, deployment, dashboards, and alerting. The apparent simplicity becomes infrastructure work. |
| **Cloud Tasks / SQS** | Reliable infrastructure-native queueing and retries, but they are queue primitives rather than developer-friendly workflow systems. You must build job state, failure inspection, replay tooling, and future orchestration yourself. Cloud Tasks also deletes exhausted tasks, so durable application-level failure records remain your responsibility. [Cloud Tasks overview](https://docs.cloud.google.com/tasks/docs/dual-overview), [retries](https://docs.cloud.google.com/tasks/docs/configuring-queues), [observability](https://docs.cloud.google.com/tasks/docs/monitor). |

My practical choice: **Trigger.dev now; Temporal only if the later workflows become a core distributed state machine rather than merely several background steps.**

I’d use **Trigger.dev Cloud** for this.

It fits the immediate PDF job particularly well: Node-native background tasks, configurable retries with backoff, concurrency controls, long-running execution, a dashboard with logs and failed runs, and run handles that can feed status back to your UI. It also supports task composition, waits, and durable multi-step workflows, so you won’t need to replace it when the process becomes “collect data → render → upload → notify.” [Trigger.dev task docs](https://trigger.dev/docs/tasks/overview), [observability and workflow features](https://trigger.dev/docs/introduction)

A clean design would be:

1. `POST /reports` creates a database record with `status = queued`.
2. It triggers a task using the report ID as an idempotency key.
3. The endpoint immediately returns `202 { reportId }`.
4. The task changes status through `running → completed` or `failed`.
5. The PDF goes to object storage—not your database—with its key recorded on the report.
6. The UI polls `GET /reports/:id` or subscribes through Trigger.dev’s realtime API.
7. After retries are exhausted, the task records a sanitized error and alerts your team.

Keep your own `reports` table as the user-facing source of truth. The vendor dashboard is for operators; users should not depend on it. Make generation idempotent because retries can repeat work: use a deterministic storage key such as `reports/{reportId}.pdf`, and don’t send notifications twice.

What else I considered:

- **Inngest — close second.** This would be my pick if event-driven, multi-step business workflows are clearly the larger destination. It runs functions on your compute, persists each completed step, retries failed steps independently, and provides detailed traces and failure metrics. It is elegant and requires less “worker infrastructure” thinking. Trigger.dev gets my vote here because PDF rendering is primarily a chunky background compute job, while Trigger.dev makes runtime sizing, logs, replay, and status integration especially direct. [Inngest functions](https://www.inngest.com/docs/learn/inngest-functions), [retries and failure handlers](https://www.inngest.com/docs/guides/error-handling)

- **Temporal Cloud.** The strongest choice for genuinely mission-critical, long-lived workflows involving compensation, human approvals, signals, or many services. Its durability model is excellent, but it introduces workers, workflow/activity separation, deterministic workflow constraints, and more operational and conceptual weight than a 40-second PDF job warrants. I would reconsider it once workflows become core business infrastructure rather than merely “several background steps.” [Temporal documentation](https://docs.temporal.io/)

- **SQS plus a Node worker.** Cheap, portable, and dependable if you are already on AWS. A dead-letter queue gives you somewhere to inspect exhausted jobs. However, you must build the worker deployment, status model, retry classification, logging correlation, admin/replay tooling, visibility-timeout handling, and later workflow orchestration yourself. SQS is also at-least-once, so idempotency remains mandatory. [AWS SQS visibility timeouts and DLQs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html)

- **AWS Step Functions.** Worth considering if you are deeply committed to AWS and future steps mostly invoke AWS services. It provides retries, catches, execution history, and visual debugging, but state-machine definitions and AWS coupling are less pleasant than ordinary TypeScript for an application-level workflow. [AWS Step Functions overview](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)

- **BullMQ with Redis.** Reasonable for a small team that wants full control and already operates Redis. It solves queueing and retries, but reliable workers, Redis durability, deployment, failure UI, monitoring, and workflow evolution remain your responsibility. I wouldn’t introduce that operational surface merely to avoid a managed job service.

So: **Trigger.dev now; Inngest if workflow orchestration is already the dominant concern; Temporal only when workflow correctness becomes mission-critical at substantial complexity.**

I’d use **Trigger.dev Cloud** for this.

It fits the immediate job unusually well: Node/TypeScript tasks, built-in queuing and configurable retries, a dashboard showing runs and errors, replaying failed runs, concurrency controls, and real-time status APIs. It also explicitly supports Puppeteer, React PDF, LibreOffice, and custom system dependencies—useful because PDF generation often needs Chromium, fonts, or native binaries. [Trigger.dev overview](https://trigger.dev/docs/introduction), [PDF and Puppeteer guides](https://trigger.dev/docs/guides/introduction), [retries and queues](https://trigger.dev/docs/tasks/overview)

A clean design would be:

```text
POST /reports
    → create report row: queued
    → trigger task with reportId
    → return 202 { reportId }

Trigger.dev task
    → mark running
    → load report inputs
    → render PDF
    → upload to object storage
    → mark completed + file URL
    → on final failure: mark failed + safe error summary

GET /reports/:id
    → queued | running | completed | failed
```

Use your database as the user-facing source of truth. Trigger.dev’s dashboard is for operators; your application’s report record is what customers poll or subscribe to. Pass only a `reportId` into the task—not the full report data—and use an idempotency key such as `report:${reportId}` so double submissions cannot generate duplicate reports. Trigger.dev supports run IDs, status retrieval, idempotency, cancellation, and replay from its dashboard. [Run lifecycle and replay](https://trigger.dev/docs/runs)

For later workflows, split work into child tasks such as `collect-data → render → upload → notify`. Parent tasks can wait for children without consuming active compute while checkpointed, and failed subtasks can be retried independently. [Task execution model](https://trigger.dev/docs/how-it-works), [waits and checkpointing](https://trigger.dev/docs/wait)

What else I’d consider:

- **Inngest** — my close second choice. It has excellent event-driven durable functions, per-step retries, saved step state, failure handlers, and detailed traces. I’d favor it if the future workflows are mostly API/database orchestration running in your existing application. For a Chromium-heavy PDF worker, Trigger.dev’s containerized task runtime and build extensions feel more natural. [Inngest functions](https://www.inngest.com/docs/learn/inngest-functions), [error handling](https://www.inngest.com/docs/guides/error-handling)

- **Temporal Cloud** — the strongest option if “multi-step workflows later” means mission-critical, long-lived workflows with signals, human approvals, compensation, and workflows lasting days or months. It is more framework and operational complexity than this forty-second PDF job currently warrants.

- **BullMQ + managed Redis** — a sensible low-cost choice if you want to own the workers. It handles retries and job flows, but you must operate Redis, deploy and scale workers, add a monitoring UI, manage dead jobs, and build more workflow semantics yourself.

- **SQS/Cloud Tasks plus a container worker** — dependable and cloud-native, with retries and dead-letter queues. It solves the PDF job, but failure inspection and future orchestration become a collection of queue, logging, database, and workflow services. I’d choose it when avoiding another SaaS is more important than developer speed.

The main caveat with Trigger.dev is dependency on another hosted platform. If these reports are regulated, extremely high-volume, or central to revenue, I’d reassess Temporal Cloud or a cloud-native queue/worker architecture. For a typical product team wanting this fixed quickly without painting itself into a corner, Trigger.dev is the pragmatic choice.

I’d use **Trigger.dev Cloud** for this.

It fits the immediate PDF job unusually well: Node/TypeScript tasks, managed workers, configurable retries and concurrency, a dashboard showing every run and attempt, and frontend subscriptions for status updates. It even documents the Puppeteer-to-PDF pattern directly. [Trigger.dev overview](https://trigger.dev/docs/introduction), [PDF/Puppeteer example](https://trigger.dev/docs/guides/examples/puppeteer), [run lifecycle and attempts](https://trigger.dev/docs/runs)

The request flow should become:

1. Create a `reports` row with status `queued`.
2. Trigger the task with the report ID and return `202 Accepted`.
3. Generate the PDF in the task and upload it to S3-compatible object storage.
4. Update the row to `completed` with its object key, or `failed` with a safe error summary.
5. Show status through Trigger.dev Realtime, SSE, or ordinary polling. Trigger.dev supports live run-state and progress metadata without building that infrastructure yourself. [Realtime documentation](https://trigger.dev/docs/realtime/overview)

A few implementation details matter more than the product choice:

- Make the job idempotent. Use the report ID as the stable identity and overwrite the same object key on retry.
- Retry transient failures—browser crashes, storage timeouts, temporary upstream failures—but not invalid input or missing permissions.
- Persist user-facing status in your own database. The vendor dashboard is operational visibility, not your product’s permanent record.
- Keep the input small: pass IDs, not HTML blobs or document buffers.
- Use an outbox pattern if losing a report between the database commit and task submission would be unacceptable.
- Put a concurrency limit around Chromium; PDF generation is memory-heavy.
- Record the run ID, attempt count, and sanitized final error so support can trace failures.

What else I considered:

| Option | Why I didn’t choose it first |
|---|---|
| **Inngest** | Very close second. Excellent event-driven durable steps, step-level retries, persisted results, failure handlers, and observability. I’d choose it if your future workflows will be driven heavily by domain events. [Inngest retries](https://www.inngest.com/docs/guides/error-handling), [observability](https://www.inngest.com/docs/platform/monitor/observability-metrics) |
| **Temporal Cloud** | The strongest long-term workflow engine: durable state, signals, timers, compensation, and workflows lasting months. But it imposes a larger programming model and operational learning curve than a 40-second PDF task justifies. I’d revisit it when workflows become mission-critical business processes rather than background jobs. [Temporal documentation](https://docs.temporal.io/) |
| **BullMQ + managed Redis** | Sensible and inexpensive if you already operate Redis and workers. It provides retries, backoff, crash recovery, and parent/child flows. You must operate Redis persistence, workers, monitoring, failed-job retention, deployment compatibility, and workflow state yourself. [BullMQ overview](https://docs.bullmq.io/), [production considerations](https://docs.bullmq.io/guide/going-to-production) |
| **AWS SQS + Step Functions** | A strong choice if you are already deeply committed to AWS. It has explicit retry/catch behavior, execution history, and redrive from failed steps, but involves more AWS plumbing and less natural TypeScript composition. [Step Functions error handling](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html), [redrive](https://docs.aws.amazon.com/step-functions/latest/dg/redrive-executions.html) |
| **A database-backed job table** | Fine for the first PDF job, especially at low volume. But you would soon build leasing, retries, dead-letter handling, dashboards, scheduling, and workflow orchestration yourself. |

My decision rule: start with Trigger.dev; choose BullMQ if minimizing vendor spend matters more and you already have reliable Redis operations; choose Temporal if those “multi-step workflows later” become a central, long-lived part of the product.

I’d use **Trigger.dev Cloud** for this.

It fits the immediate PDF job particularly well: Node/TypeScript tasks run outside the web request, retries use configurable exponential backoff, each run has logs and traces in a dashboard, and there is built-in support for Puppeteer and system packages often needed by PDF renderers. It also supports nested tasks and multi-step workflows, so this does not become a throwaway queue when your workflows grow. [Tasks and retries](https://trigger.dev/docs/tasks/overview), [Puppeteer/build extensions](https://trigger.dev/docs/config/extensions/overview), [deployment model](https://trigger.dev/docs/deployment/overview).

A sensible flow would be:

1. The request inserts a `report_jobs` record with status `queued`.
2. It triggers the task using the job ID as an idempotency key.
3. It immediately returns `202 Accepted` with that job ID.
4. The task changes the status to `running`, generates the PDF, uploads it to object storage, then records `completed` and the object key.
5. On final failure, it records `failed`, a sanitized error, attempt count, and timestamps.
6. The UI polls `/reports/:id`, or subscribes to run updates if you want live progress. Trigger.dev supports subscriptions to status and custom progress metadata. [Run updates](https://trigger.dev/docs/realtime/backend/subscribe).

Keep your database—not Trigger.dev—as the user-facing source of truth. That lets support staff inspect failures, users retry a failed report, and you change job providers later. Also make generation idempotent: retries must overwrite the same object key or safely detect an already-generated report.

What else I’d consider:

| Option | When I’d choose it | Why I wouldn’t start there here |
|---|---|---|
| **Inngest** | You want durable, event-driven workflows while keeping execution on your own containers | Very close second. It has excellent step-level retries, saved step results, failure handlers, and observability. Trigger.dev gets the nod because hosted task compute and Puppeteer/container customization are especially convenient for PDF generation. [Inngest functions](https://www.inngest.com/docs/learn/inngest-functions), [retry behavior](https://www.inngest.com/docs/guides/error-handling) |
| **Temporal Cloud** | Workflows will become business-critical, long-lived, highly stateful, or require signals, compensation, and strong durability semantics | Most powerful option, but introduces workers, deterministic workflow rules, and more operational/conceptual weight than a 40-second report job warrants. [Temporal overview](https://temporal.io/) |
| **BullMQ + Redis** | You already operate Redis reliably and want maximum control with minimal vendor dependency | Good Node queue, but you own deployment, Redis durability, dashboards, alerting, stalled-job behavior, and workflow evolution. Cheap in service fees; not necessarily cheap operationally. |
| **SQS + worker/Lambda** | You are firmly standardized on AWS and prefer native infrastructure | Extremely durable and straightforward for jobs, with retries and a dead-letter queue. Multi-step workflows generally push you toward Step Functions, and useful per-job visibility requires more assembly. AWS recommends configuring a DLQ and sizing visibility timeout around worker duration. [AWS SQS/Lambda guidance](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-lambda-function-trigger.html) |
| **Cloud Tasks / Pub/Sub** | You are similarly committed to GCP | Solid managed primitives, but observability and future workflow orchestration remain partly yours to build. |

My decision would change to Temporal if “multi-step later” actually means workflows lasting hours or days, waiting for people or external events, with compensation and strict audit requirements. If it means “fetch data → render → upload → email,” Trigger.dev is the more proportionate choice.

I’d use **Trigger.dev Cloud** for this.

It fits the immediate problem unusually well: Node/TypeScript tasks run on managed workers outside your HTTP server, can run without request timeouts, retry with exponential backoff, and expose each run in a dashboard. It also supports child tasks, waits, branching, concurrency limits, and idempotency keys, so it can grow into multi-step workflows without an early platform change. [Trigger.dev tasks](https://trigger.dev/docs/tasks/overview), [pricing and execution model](https://trigger.dev/pricing)

The request flow should become:

1. Create a `report_jobs` row with status `queued`.
2. Trigger `generate-report` using the job ID as an idempotency key.
3. Return `202 Accepted` immediately with your job ID.
4. The task loads the data, generates the PDF, uploads it to object storage, and marks the job `completed`.
5. Your UI polls `GET /report-jobs/:id` or subscribes for status changes.
6. After retries are exhausted, mark it `failed` with a sanitized error code/message.

Keep your database as the user-facing source of truth. The service dashboard is for operators; don’t make customers depend directly on Trigger.dev run IDs. Store that run ID alongside your job record for debugging.

Important implementation details:

- Make generation idempotent: use a deterministic object key such as `reports/{jobId}.pdf` and upsert the result.
- Retry transient failures—browser crashes, storage timeouts, network errors—but not invalid input or permanently missing data.
- Pass IDs rather than a large report payload; reload authoritative data inside the task.
- Choose enough memory for Chromium/Puppeteer. Trigger.dev offers selectable worker sizes and bills managed compute per second. [Current pricing](https://trigger.dev/pricing)
- Add an `onFailure` hook to update your job row and alert Sentry/Slack.
- Set a sensible maximum duration even though long tasks are supported, so a wedged renderer cannot run indefinitely. [Maximum duration](https://trigger.dev/docs/runs/max-duration)

What else I considered:

- **Inngest:** My runner-up. It has excellent TypeScript workflow-as-code, automatic step retries, persisted step results, failure handlers, and strong run visibility. I would prefer it when the future multi-step/event-driven workflows are the dominant requirement. The distinction is that Inngest generally orchestrates functions running on your compute, while Trigger.dev’s managed workers are especially convenient for CPU/memory-heavy PDF generation and browser dependencies. [Inngest functions](https://www.inngest.com/docs/learn/inngest-functions), [retry behavior](https://www.inngest.com/docs/guides/error-handling)

- **AWS Step Functions + ECS/Fargate or Lambda:** A strong choice if you are already deeply committed to AWS. Standard workflows have visual execution history, configurable retries, and failed executions can be redriven from the unsuccessful step. It is more infrastructure and IAM/configuration than I would introduce for one report task. Chromium PDF generation often fits ECS/Fargate more comfortably than Lambda. [Workflow types](https://docs.aws.amazon.com/step-functions/latest/dg/choosing-workflow-type.html), [redrive](https://docs.aws.amazon.com/step-functions/latest/apireference/API_RedriveExecution.html)

- **Temporal Cloud:** The most capable option for genuinely complex, long-lived business workflows. Its durability and workflow history are excellent, but it requires operating worker processes and learning deterministic workflow constraints. For a 40-second report job it is probably too much platform; Temporal Cloud currently has a $100/month minimum Essentials plan. [Temporal Cloud pricing](https://github.com/temporalio/documentation/blob/main/docs/evaluate/temporal-cloud/pricing.mdx)

- **BullMQ + Redis:** Cheap, familiar, and flexible, but you own Redis, worker deployment, scaling, dead-letter conventions, monitoring, and future orchestration semantics. Fine when you deliberately want infrastructure ownership; it doesn’t satisfy the “see what failed” requirement as cleanly without adding Bull Board, metrics, and alerting.

So the short answer is: **Trigger.dev now; Inngest if workflows rather than heavy background compute are clearly becoming the center of the system; Step Functions if your cloud is already AWS-standardized.**

I’d use **Trigger.dev Cloud** for this.

It fits the immediate PDF job well: TypeScript tasks execute outside the web request, can run for extended periods, support configurable retry/backoff, expose run status, and provide logs and manual replay through the dashboard. It also supports composing tasks into larger workflows later. [Trigger.dev task docs](https://trigger.dev/docs/tasks/overview), [retry and error handling](https://trigger.dev/docs/errors-retrying), [run lifecycle](https://trigger.dev/docs/runs).

The request flow would become:

1. Create a `report_jobs` row with status `queued`.
2. Trigger the background task, passing only the report/job ID.
3. Return `202 Accepted` immediately with that ID.
4. The task loads the data, renders the PDF, uploads it to object storage, and marks the job `completed`.
5. The UI polls or subscribes for status and displays the download link.
6. After retries are exhausted, mark it `failed` with a sanitized error code/message.

Keep the application’s job table even though Trigger.dev has its own run dashboard. The dashboard is for operators; your database is the user-facing source of truth and avoids binding the product UI to one vendor.

Important implementation details:

- Make the job idempotent. Use the job ID as both the Trigger.dev idempotency key and the object-storage key, such as `reports/{jobId}.pdf`.
- Separate transient failures from permanent ones. Retry browser crashes, network failures, and storage timeouts; do not retry invalid report input.
- Store the provider run ID, attempt count, timestamps, error category, and final object key.
- Set explicit concurrency so a surge of Chromium/PDF jobs cannot exhaust memory.
- Generate short-lived signed download URLs rather than storing the PDF in your database.
- Add an `onFailure` handler for database status updates and alerts—but also reconcile jobs stuck in `running`, since Trigger.dev documents that `onFailure` does not cover every terminal status.

What else I’d consider:

| Option | When I’d choose it | Why I wouldn’t start there |
|---|---|---|
| **Temporal Cloud** | Workflows become core business infrastructure: days/months long, human approvals, compensation, complex branching, very high reliability requirements | Excellent durability and TypeScript support, but workers, workflow/activity separation, determinism rules, and deployment versioning create more conceptual and operational weight for a 40-second PDF task. [Temporal docs](https://docs.temporal.io/), [TypeScript SDK](https://typescript.temporal.io/) |
| **Inngest** | You want lightweight event-driven workflows deployed alongside existing application compute | Very good alternative: steps are checkpointed and retried independently, with persisted errors and failure handlers. For compute-heavy PDF generation, I slightly prefer Trigger.dev’s task-oriented execution model. [Inngest functions](https://www.inngest.com/docs/learn/inngest-functions), [steps](https://www.inngest.com/docs/learn/inngest-steps) |
| **BullMQ + Redis** | You already operate Redis reliably and want maximum control or low vendor dependence | Solid queue, but you own workers, autoscaling, Redis durability, deployment coordination, stale-job recovery, monitoring, and usually a separate dashboard. Multi-step durability becomes application code. |
| **SQS/Cloud Tasks + workers** | You are deeply committed to one cloud and only need straightforward jobs | Cheap and dependable primitives, but job state, retry classification, observability, orchestration, and workflow evolution are largely yours to build. |
| **AWS Step Functions** | You are all-in on AWS and want cloud-native orchestration | Capable execution history and retry/redrive support, but more vendor coupling and workflow-definition ceremony than I’d accept for this use case. [AWS Step Functions guide](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) |

My decision rule: **Trigger.dev now; Temporal Cloud only if future workflows become sufficiently complex that durable orchestration is itself a central platform requirement.** I would not build the first version directly on a raw queue unless your team already has strong queue/worker infrastructure.

I’d use **Trigger.dev Cloud**.

It fits this workload unusually well: Node/TypeScript tasks, long-running PDF generation, automatic retries, configurable concurrency, a dashboard with logs and traces for every attempt, and support for composing tasks into workflows later. It also runs the background worker compute, so the web request is no longer responsible for surviving those 40 seconds. Trigger.dev provides a Realtime API and React hooks if you want live progress in the UI. [Trigger.dev overview](https://trigger.dev/docs/introduction) · [observability](https://trigger.dev/product/observability-and-monitoring)

The request path should become:

1. Create a `report_jobs` row with status `queued`.
2. Trigger the task with that row’s ID as the idempotency key.
3. Return `202 Accepted` and the job ID immediately.
4. The task loads the report data, renders the PDF, uploads it to object storage, and marks the row `completed`.
5. The UI polls your status endpoint or subscribes to updates.
6. On terminal failure, store a safe user-facing error plus the Trigger.dev run ID; engineers inspect the detailed exception and attempt history in Trigger.dev.

Keep PDFs in S3/GCS/R2 rather than task results or your database, and make the task idempotent because any retry system can repeat work. A deterministic storage key such as `reports/{jobId}.pdf` helps.

What I considered:

- **Inngest — close second.** Excellent event-driven durable execution, independently retried steps, persisted state, failure handlers, and strong run observability. I’d favor it if your future workflows will be primarily event-driven and you want functions coordinated while running on your existing compute. [Functions](https://www.inngest.com/docs/learn/inngest-functions) · [retries](https://www.inngest.com/docs/guides/error-handling) · [observability](https://www.inngest.com/docs/platform/monitor/observability-metrics)
- **Temporal Cloud.** The strongest choice when workflows become genuinely complex—days-long processes, signals, compensation, extensive branching, or mission-critical recovery. For one 40-second PDF job it introduces more concepts and worker operations than I’d accept initially.
- **AWS Step Functions plus SQS/ECS or Lambda.** Robust and sensible if you are already deeply committed to AWS. It requires more infrastructure and its workflow definitions are less pleasant than ordinary TypeScript. PDF rendering also commonly pushes you toward container workers rather than Lambda.
- **BullMQ plus Redis.** Cheap, familiar, and fully controlled. But you must operate Redis and workers, build deployment/draining behavior, and assemble monitoring and workflow visibility yourself. I’d use it only if avoiding a managed service is an explicit requirement.
- **A plain cloud queue.** SQS, Cloud Tasks, or Service Bus solves request decoupling and retry delivery, but not the future workflow and debugging requirements by itself.

So my default decision is **Trigger.dev now, with your own `report_jobs` table as the product-facing source of truth**. I’d switch the recommendation to Inngest if event-driven orchestration is central, or Temporal if those “multi-step workflows” are expected to become a core, high-complexity business system.

I’d use **Trigger.dev Cloud**.

It fits this case especially well: Node/TypeScript-native background tasks, configurable retries/backoff, concurrency limits, detailed run/attempt history, logs, replaying failed runs, and child tasks for later multi-step workflows. It also deploys tasks as container images and has a built-in Puppeteer extension—useful if the PDFs come from HTML and Chromium. [Tasks and retries](https://trigger.dev/docs/tasks/overview), [observability and runs](https://trigger.dev/docs/runs), [Puppeteer/build extensions](https://trigger.dev/docs/config/extensions/overview).

A sensible design would be:

1. `POST /reports` validates input, inserts a `report_jobs` row, triggers the task with `jobId`, and immediately returns `202 { jobId }`.
2. The task loads immutable report inputs, renders the PDF, and uploads it to object storage.
3. It updates the row to `succeeded` with an object key, or `failed` with a sanitized error and the Trigger.dev run ID.
4. The UI polls `GET /reports/:jobId`, subscribes to run updates, or receives an SSE/WebSocket notification.
5. Downloads use a short-lived signed object-storage URL.

Keep the database record as your user-facing source of truth; the vendor dashboard is the operator-facing view. Make the task idempotent using the job ID as both the idempotency key and deterministic storage key, because retries can occur after rendering or uploading succeeded but before acknowledgment.

What I’d also consider:

- **Inngest:** the closest alternative, and perhaps my pick if the future system is strongly event-driven. It persists step results, retries only the failed step, supports failure handlers, and has step-level traces. Its persistent worker mode works well on ordinary container hosts, though it currently requires Node 22.4+ for TypeScript workers. [Execution model](https://www.inngest.com/docs/learn/how-functions-are-executed), [retry behavior](https://www.inngest.com/docs/guides/error-handling), [container workers](https://www.inngest.com/docs/setup/connect). Trigger.dev gets the edge here because PDF/browser workloads feel more directly catered for.

- **Temporal Cloud:** the strongest long-term choice for critical, complicated workflows involving days-long waits, human approvals, compensation, or strict recovery guarantees. It resumes workflows after crashes or infrastructure failures. It is also substantially more machinery and conceptual overhead than a 40-second report job needs today. [Temporal documentation](https://docs.temporal.io/).

- **AWS Step Functions + ECS/Fargate/Lambda:** good if you are already deeply committed to AWS and want IAM-native orchestration and visual execution history. Standard workflows are durable and auditable for up to a year; the tradeoff is more AWS plumbing and workflow definitions outside ordinary application code. [Workflow types](https://docs.aws.amazon.com/step-functions/latest/dg/choosing-workflow-type.html).

- **BullMQ + managed Redis:** inexpensive and flexible, with no workflow vendor dependency. But you own workers, Redis durability, deployment, stalled-job handling, dashboards, alerts, and workflow evolution. I’d choose it only if infrastructure ownership or high-volume unit economics justified that operational burden.

My practical call: start with **Trigger.dev Cloud plus your own `report_jobs` table and object storage**. Reevaluate Temporal only if the later workflows become business-critical processes rather than simply chains of background tasks.

Here is the recommendation tailored to a **Node.js** stack running on standard cloud infrastructure, moving from synchronous 40-second PDF rendering to a background architecture that supports retries, observability, and future multi-step workflows.

---

### **Primary Recommendation: BullMQ (with Redis) + Bull-Board**

If you want a native, flexible, and developer-friendly solution that integrates tightly with Node.js, **[BullMQ](https://docs.bullmq.io/)** (backed by Managed Redis like AWS ElastiCache, GCP Memorystore, Upstash, or Redis Cloud) is the best fit.

#### **Why BullMQ fits your requirements:**
1. **Offloading & Retries:** Built-in exponential backoff, configurable retry counts, custom rate-limiting, and dead-letter queues.
2. **Observability & Visibility:** Pair it with **Bull-Board** (a drop-in, lightweight web UI) or **BullMQ Pro / Arena** to easily inspect job statuses, view error stack traces on failure, and trigger manual retries.
3. **Multi-step Workflows:** BullMQ has native support for **Flows / Parent-Child Jobs** (e.g., `Job A -> [Job B1, Job B2] -> Job C`), allowing you to chain multi-step generation, notification, and storage workflows without extra orchestration tooling.
4. **Node Native:** Written in TypeScript/Node.js, minimal operational overhead if you already run Redis.

---

### **Alternative Options Considered**

| Service / Tool | Pros | Cons | Best When... |
| :--- | :--- | :--- | :--- |
| **Temporal.io / Inngest** *(Durable Execution Engines)* | • State-machine level workflow orchestration as code.<br>• Built-in step checkpoints, retries, and failure tracing.<br>• Zero external broker setup with Inngest. | • Temporal requires self-hosting clusters or paid Temporal Cloud.<br>• Slightly steeper mental model than simple queues. | Future multi-step workflows will be **complex, long-running (hours/days), or require human-in-the-loop approvals**. |
| **Cloud-Native SQS + Lambda / Worker** *(AWS SQS / GCP Cloud Tasks)* | • Fully managed, zero server maintenance.<br>• Native Dead Letter Queues (DLQ) and CloudWatch/GCP Monitoring. | • Multi-step workflows require Step Functions / Workflows (extra vendor lock-in).<br>• Local development and end-to-end testing can be clunky. | Your team strictly prefers **serverless / cloud-native** primitives over running a persistent worker/Redis. |
| **RabbitMQ / Celery (Node/AMQP)** | • Powerful routing topologies and enterprise-grade message broker. | • Overkill for background jobs.<br>• Extra operational overhead and weaker native TypeScript flow primitives compared to BullMQ. | You already have an existing RabbitMQ cluster deployed in production. |

---

### **Suggested Architecture**

```
Client (App)
   │
   ├─► 1. POST /api/reports/generate ──► API Server (Node)
   │   ◄── Returns 202 Accepted { jobId } ──┘  │
   │                                           ▼
   │                                     BullMQ Producer ──► Redis Queue
   │                                                               │
   │   2. Poll /api/reports/:id/status OR WebSocket/SSE            │
   │   ◄──────────────────────────────────────────────             ▼
   │                                                        BullMQ Worker(s)
   │                                                        • Generates PDF (Puppeteer/Playwright)
   │                                                        • Uploads to S3/GCS
   │                                                        • Emits completion / failure
   ▼
Bull-Board (Admin UI) ◄── Inspect failed jobs, retry manually, review execution traces
```

### **Recommendation Summary:**
* **Start with BullMQ + Redis + Bull-Board:** Simple to implement today for PDF offloading with excellent visibility into failures, with built-in flow support ready for your upcoming multi-step needs.
* **Consider Inngest or Temporal:** Only if your upcoming multi-step workflows involve complex branching, multi-day timers, webhooks, or multi-service choreography.

For this workload (Node.js, long-running PDF generation, retries, failure observability, and future multi-step orchestration), the recommendation depends on whether you prefer **code-as-workflows (modern orchestration engine)** or a **traditional message/task queue**.

---

### Top Recommendation: **Temporal** (or Inngest)

If you plan to build multi-step workflows later, **Temporal** is the best-in-class choice.

* **Why Temporal?**
  * **Built for long-running / multi-step tasks:** Workflows are written as regular TypeScript/Node.js code. If step 1 (fetch data) succeeds and step 2 (render PDF via Puppeteer/Chromium) crashes, only step 2 retries without re-running step 1.
  * **First-class retries & timeouts:** Fine-grained retry policies (exponential backoff, non-retryable errors) per activity/step.
  * **Observability UI:** Out of the box, you get a web UI that visualizes every execution, showing exactly which step failed, stack traces, payload inputs/outputs, and execution history.
  * **Hosting:** Available as fully managed (Temporal Cloud) or self-hosted in Docker/K8s.

> **Alternative managed modern option:** **Inngest** or **Trigger.dev**. If you want zero infrastructure setup and serverless-first step functions in TypeScript without managing worker clusters, Inngest is significantly faster to get running on standard Node/Next.js hosting.

---

### Comparison of Options Considered

| Solution | Best For | Strengths | Trade-offs / Drawbacks |
| :--- | :--- | :--- | :--- |
| **Temporal** *(Recommended)* | Complex multi-step workflows & high reliability | Durable execution, visual execution history, state recovery after worker crashes | Moderate learning curve; requires running Temporal server or using Temporal Cloud. |
| **Inngest / Trigger.dev** | Fast developer setup in modern Node ecosystems | Step functions as code, built-in dashboards/retries, minimal infra burden | Cloud-managed SaaS dependency (though Trigger.dev can be self-hosted). |
| **BullMQ + Redis + Bull-Board** | Traditional lightweight queueing | Extremely simple, native Node/TypeScript, low overhead, no external SaaS required | Multi-step workflows require manual saga/state tracking; Redis persistence needs management. |
| **Cloud-Native Queues** *(AWS SQS / GCP Cloud Tasks)* | Basic async offloading | Highly scalable, zero maintenance, built-in DLQ (Dead Letter Queue) | Minimal visibility UI without custom dashboards; multi-step orchestration requires AWS Step Functions / GCP Workflows (awkward JSON/YAML definitions). |
| **Cloud Step Functions / Workflows** | Pure cloud-native multi-step pipelines | Fully managed, visual state machine | Vendor lock-in, coordinating with external Node workers can be clunky compared to code-first orchestration. |

---

### How the PDF Architecture Looks in Practice

1. **Client Request:** User requests report → HTTP endpoint enqueues workflow/job ID (`POST /api/reports`) → returns `202 Accepted` with a `jobId` immediately.
2. **Background Processing (Worker):**
   * Worker picks up the job.
   * Runs PDF generation in an isolated background container (giving Puppeteer/Chromium sufficient RAM/CPU without starving your web server).
   * Saves the generated PDF to S3 / GCS and generates a signed URL.
   * Updates job status in DB or workflow state to `completed`.
3. **Client Polling / Realtime:**
   * Client polls `GET /api/reports/:jobId` or listens over WebSocket/SSE.
   * On completion, displays the download link or previews the PDF.

### Summary Recommendation
* **If you want simple, self-hosted, and standard:** Start with **BullMQ + Redis** with `bull-board` for monitoring.
* **If you know you have multi-step orchestration coming up:** Go straight to **Temporal** (or **Inngest**) so you don't have to redesign your state and retry logic later.

For your requirements—**Node.js on a standard cloud provider**, moving a heavy 40-second job out of the HTTP request lifecycle, built-in **retries**, **visibility/inspection for failures**, and room to expand into **multi-step workflows**—here are the top recommendations and alternatives.

---

### Top Recommendation: **Temporal** (or **Inngest** for lightweight DX)

#### 1. Primary Choice for Robust Workflows: **Temporal** (Temporal Cloud or Self-Hosted)
* **Why it fits best:**
  * **Code-as-Workflows:** You write regular async Node/TypeScript code (`await step1()`, `await generatePdf()`). Temporal guarantees durable execution—if a worker crashes mid-way through a multi-step workflow, it resumes without losing state.
  * **Built-in Retries & Backoff:** Fine-grained retry policies per activity (e.g., PDF rendering timeouts, memory issues, network retries).
  * **Visibility & Debugging:** Out of the box, you get an execution history UI showing every state transition, input/output payload, stack trace, and failure reason.
  * **Cloud-agnostic:** Runs on any VM/container (ECS, GKE, Cloud Run, Kubernetes, Fly.io, etc.) or via Temporal Cloud.

#### 2. Modern Serverless / DX Alternative: **Inngest**
* **Why it’s worth considering:**
  * Zero-infrastructure orchestration for Node/TypeScript. You deploy simple handler functions to your existing Node server or serverless setup.
  * Native support for `step.run()` for multi-step flows, automatic retries, concurrency limits, and a clean web dashboard for inspecting failed runs.

---

### Alternative Options Considered & Trade-offs

| Service / Tool | Pros | Cons / Why it might not be the best primary fit |
| :--- | :--- | :--- |
| **BullMQ + Redis** *(Traditional Queue)* | • Standard in the Node ecosystem.<br>• Low latency, simple to set up.<br>• Free UI plugins (e.g., Bull-Board) for monitoring and retries. | • **Multi-step workflows are brittle** to orchestrate by hand (parent-child dependencies, sagas, state management).<br>• Requires maintaining Redis and worker infrastructure. |
| **Cloud-Native Queues**<br>*(AWS SQS + Lambda / GCP Cloud Tasks)* | • Fully managed, virtually zero ops overhead.<br>• Cloud Tasks has native HTTP-target invocation and rate limiting. | • SQS/Cloud Tasks are plain message brokers; building multi-step branching/chaining requires orchestrators like **AWS Step Functions** or **GCP Workflows**, which lead to vendor lock-in and JSON/YAML/ASL definition overhead. |
| **Trigger.dev** | • Tailored specifically for long-running Node/TypeScript background tasks.<br>• Excellent UI and step-based workflows. | • Newer ecosystem compared to Temporal, though rapidly maturing. |
| **Celery / RabbitMQ / Kafka** | • Battle-tested for message routing. | • Celery is primarily Python-first; Kafka is heavy event-streaming overkill for task queues. |

---

### Recommended Architecture Pattern for your 40s PDF generation

1. **HTTP Endpoint (`POST /api/reports`):**
   * Validates request, writes a `Report` record to the DB with status `PENDING`.
   * Dispatches the workflow/job (`reportId`, `userId`, `filters`).
   * Returns immediately with `202 Accepted` and `{ reportId, status: "PENDING" }`.
2. **Worker Process:**
   * Picks up the job, fetches data, launches the headless browser/renderer (e.g., Puppeteer, Playwright), uploads to S3/GCS.
   * Updates status to `COMPLETED` with the download URL, or `FAILED` with retry logs.
3. **Client Notification:**
   * Polls `GET /api/reports/:id` or subscribes to a WebSocket / Server-Sent Events (SSE) channel.

Here is the recommended solution and a breakdown of alternatives evaluated against your requirements (Node.js, background processing, retries, dead-letter/failure observability, and future multi-step workflows).

---

### Top Recommendation: **Temporal** (or **Inngest** for serverless/managed simplicity)

#### 1. **Temporal** (Best for robust orchestration & complex workflows)
* **How it fits:**
  * **Async Execution & Retries:** Moves heavy 40-second PDF rendering (e.g., Puppeteer, Chromium, PrinceXML) to isolated Node.js worker processes with customizable, automatic exponential retries.
  * **Observability:** Excellent Web UI showing execution history, step-by-step inputs/outputs, stack traces on failure, and manual retry/replay options.
  * **Future Multi-step Workflows:** Tailor-made for workflows (e.g., *Step 1: Fetch data → Step 2: Render PDF → Step 3: Upload to S3 → Step 4: Send Email / Notify Webhook*). Code-as-workflows means you write normal Node.js async/await code that is fully durable and resilient to worker crashes.
  * **Hosting:** Available as fully-managed **Temporal Cloud** or self-hosted via Docker/Kubernetes on any cloud.

#### *Alternative Recommendation:* **Inngest** (Best developer experience & fastest setup)
* If managing Temporal workers/cluster is more infrastructure overhead than you want, **Inngest** gives you durable execution, retries, multi-step flow chaining (`step.run()`), and a failure/debugging dashboard with zero queue/worker infrastructure to maintain.

---

### Comparison of Other Options Considered

| Option | Pros | Cons / Why It Ranked Lower |
| :--- | :--- | :--- |
| **BullMQ + Redis** | • Lightweight, standard Node.js choice<br>• Fast to set up with existing Redis<br>• Good dashboard options (Bull-Board) | • **Weak orchestration:** Multi-step pipelines require manual state management or chaining jobs with parent/child dependencies.<br>• Redis is in-memory; scaling very long-running or complex persistent workflows gets messy. |
| **Cloud-Native Queues**<br>*(AWS SQS + Lambda / GCP Cloud Tasks)* | • Fully managed, no servers to run<br>• Built-in DLQs (Dead Letter Queues) | • SQS/Cloud Tasks only solve the single queue problem.<br>• For multi-step workflows, you must stitch them together with **AWS Step Functions** or **GCP Workflows**, which introduces vendor lock-in, complex JSON/YAML/ASL definitions, and local debugging friction. |
| **Hatchet** | • Fast, distributed, built specifically for TypeScript/Node & Python<br>• Good dashboard and built-in DAG/workflow engine | • Great modern option, but smaller ecosystem and community maturity compared to Temporal. |
| **Celery / Airflow** | • Mature tooling for batch/ETL workloads | • Python-first ecosystem (poor Node.js native ergonomics).<br>• Airflow is heavy and intended for batch ETL scheduling, not transactional user-triggered event processing. |

---

### Recommended High-Level Architecture

```
[ User Request ]
       │
       ▼
[ Node.js API ] ──► Starts Workflow ──► Responds immediately with `{ jobId / workflowId }`
       │
       ▼
[ Temporal / Inngest Worker ]
       ├─► Step 1: Fetch data / render HTML template
       ├─► Step 2: Generate PDF (Headless Chrome / Puppeteer)
       ├─► Step 3: Upload to Cloud Storage (S3 / GCS)
       └─► Step 4: Dispatch push notification / websocket / email
```

* **Client polling / update:** Provide an endpoint `GET /reports/:id/status` (or push via WebSockets/SSE) so the UI can replace the blocking spinner with a non-blocking progress state.

Here is a recommendation tailored for a **Node.js application running on standard cloud infrastructure**, looking to offload heavy operations (40s PDF generation), provide retries, failure observability, and support future multi-step workflows.

---

### **Primary Recommendation: Temporal.io (or Inngest)**

If you prioritize **multi-step workflows, built-in state management, durable retries, and end-to-end failure observability**, use a **code-as-workflows orchestrator**:

#### **Choice 1A: Temporal (Self-hosted or Temporal Cloud)**
* **Why it fits:**
  * **Durable execution:** Each step (activity) in a workflow is checkpointed automatically. If your Node process dies midway or the PDF renderer crashes, it resumes from the last step or retries cleanly.
  * **Failure visibility:** The Temporal Web UI gives you an exact execution timeline, input/output for each activity, stack traces for failures, and one-click retries.
  * **Multi-step ready:** Chaining PDF generation $\rightarrow$ uploading to S3 $\rightarrow$ sending an email/webhook $\rightarrow$ updating the DB is written as standard async Node.js code without manual state machines.
  * **Timeouts & Retries:** Declarative retry policies (exponential backoff, non-retryable error types, heartbeat timeouts for long generation jobs).

#### **Choice 1B: Inngest (Managed / Developer-friendly alternative)**
* If you want zero infrastructure setup (no separate Temporal cluster to manage) and work with serverless or standard Node backends, **Inngest** offers a similar event-driven, durable workflow model with an excellent dashboard and step-function style DX via pure TypeScript/Node functions (`step.run()`).

---

### **Alternative Choice: BullMQ (Redis-based Queue)**
* **When to pick this instead:**
  * If your multi-step needs are relatively modest (e.g., job $\rightarrow$ callback) and you already run **Redis** in your stack.
* **Why it works:**
  * Native Node.js/TypeScript first.
  * Robust retry policies with exponential backoff, dead-letter queues (failed jobs queue), and progress reporting.
  * UI available via **Bull-Board** to inspect failed jobs, see error stacks, and trigger manual retries.
  * Built-in support for parent-child job hierarchies (flows/child jobs).
* **Trade-off vs Temporal/Inngest:** Complex multi-step sagas, long-lived pauses, or dynamic decision branching require more custom glue code compared to durable workflow engines.

---

### **What Else Was Considered & Why They Were Deprioritized**

| Solution | Why Considered | Why Deprioritized / Caveats |
| :--- | :--- | :--- |
| **AWS SQS + Lambda / Worker** | Standard cloud-native queue | Lacks built-in dashboard for failed jobs (CloudWatch metrics/logs are disjointed), multi-step requires adding AWS Step Functions, and PDF generation (often needing Chromium/Puppeteer) on Lambda hits size and memory limits. |
| **AWS Step Functions** | Robust multi-step state machine | Defining workflows via JSON/YAML (ASL) adds significant development friction compared to code-first workflows in Node. |
| **Celery / RabbitMQ** | Standard background workers | Celery is primarily Python-centric (Node support is second-class); RabbitMQ requires significant boilerplate for retries, backoff, and dead-letter queue inspection UI. |
| **Google Cloud Tasks / Pub/Sub** | Simple HTTP-target queuing | Great for single dispatches, but lacks native workflow orchestration and rich visualization for failed multi-step pipelines out of the box. |

---

### **Summary Architecture for PDF Generation**

1. **Client Request:** `POST /reports` $\rightarrow$ API pushes an event / starts workflow execution and immediately returns `202 Accepted` with a `jobId` or polling URL (or push via WebSockets/SSE).
2. **Worker Step 1:** Fetch data & render PDF (isolated worker process with Puppeteer/Playwright).
3. **Worker Step 2:** Upload PDF to Object Storage (S3 / GCS) & generate signed URL.
4. **Worker Step 3:** Notify user / dispatch webhook / persist completion status.
5. **Observability:** Check the Temporal/Inngest or Bull-Board UI for real-time trace, failures, and manual retries.

**Inngest.**

Enqueue on request (`report/requested`), return a job/report id, generate the PDF in a function. You get retries, a run history for failures/replays, and `step.run` when you later split “fetch → render → upload → notify.” Node/TS-first, runs on a normal cloud next to your app—no Redis queue to own.

**Also considered**

| Option | Why not first |
|---|---|
| **Trigger.dev** | Closest alternative; excellent for long PDF jobs. Prefer if “run this for minutes” matters more than event/step workflows. |
| **BullMQ + Redis** | Fine and cheap at scale, but you build the failure UI (Bull Board) and multi-step yourself. |
| **Temporal** | Best when workflows get serious (sagas, long waits). Heavier than you need for “PDF off the request.” |
| **SQS + worker (± Step Functions)** | Solid AWS path; weaker DX and you assemble retries/visibility/orchestration. |

Pattern: respond `202` + id immediately; poll or push when the report is ready. Don’t keep the spinner on the request.

**Use Inngest** (or Trigger.dev if you already lean that way). Same shape: enqueue from the request, return a job/report id, poll or webhook when the PDF is ready.

### Why
- **Off the request**: `inngest.send(...)` / enqueue and respond in milliseconds.
- **Retries**: per-step retry with backoff, no hand-rolled worker loop.
- **Failure visibility**: dashboard of failed runs, step errors, replay.
- **Multi-step later**: first-class steps (fetch → render PDF → upload → notify) without bolting on a second orchestrator.
- **Node on a normal cloud**: your API + worker stay in the same Node app (or a sibling service) on ECS/Cloud Run/Railway/etc.; you are not rewriting around Lambda timeouts.

Pattern: `POST /reports` → create `reportId` (pending) → send event → 202 + id → worker writes PDF to storage → mark complete → client polls `GET /reports/:id` or gets a webhook.

### Also considered

| Option | Verdict |
|---|---|
| **Trigger.dev** | Same niche as Inngest. Fine pick if the team prefers it; I would not run both. |
| **BullMQ + Redis + Bull Board** | Solid if you refuse another vendor and already run Redis. Retries and a failure UI are good; multi-step is DIY (chains / BullMQ flows) and you own ops, poison messages, and dashboards. |
| **SQS + DLQ (+ Step Functions later)** | Clean AWS-native for “queue + retries + dead letter.” Weak for multi-step until you add Step Functions; more glue, less Node ergonomics. |
| **Temporal** | Best when workflows get long-lived, branched, or human-gated. Heavy for “render a PDF with retries”; keep it as the upgrade path if Inngest/Trigger start to feel thin. |
| **pg-boss / Graphile Worker** | Fine for simple jobs if Postgres is the only infrastructure you want. Observability and workflow story are thinner. |

**Skip for this problem:** doing PDF gen in the HTTP handler (what you have), fire-and-forget without a DLQ/dashboard, or jumping straight to Temporal before you have real multi-step pain.

**Practical default:** Inngest now; BullMQ if “no SaaS orchestrator” is a hard constraint; Temporal only when workflow complexity clearly outgrows step-based job runners.

**Trigger.dev** — long-running Node tasks, retries, a failure dashboard, and real multi-step workflows when you need them. Enqueue from the request, return a job id, poll or webhook when the PDF is ready.

### Why that one
- Fits a 40s PDF job (Chromium-friendly) without stuffing it into the HTTP request.
- Retries and dead-letter style failure visibility out of the box.
- Steps/workflows are a first-class path later, not a rewrite.
- Stays in the Node app model on a normal cloud (their cloud or self-host).

### Also considered
| Option | Verdict |
|---|---|
| **BullMQ + Redis** | Strong default if you already run Redis and want full ownership. Retries and Bull Board cover failure visibility; multi-step is DIY job chaining. |
| **Inngest** | Excellent for event-driven steps and observability. Slightly less natural for heavy Chromium/PDF workers unless you wire dedicated compute carefully. |
| **Temporal** | Best durable-workflow engine, overkill for “generate PDF + retry,” and more ops than you want on a normal Node stack. |
| **SQS / Cloud Tasks + workers** | Fine primitives; you build retry policy, failure UI, and later orchestration yourself. |
| **Step Functions** | Good workflow graph, weak day-to-day Node DX for app logic. |

**Practical split:** Trigger.dev if you want the platform to own retries/visibility/workflows; BullMQ if Redis is already in the stack and you prefer owning the queue.

**Inngest** — best fit for your list without standing up queue infra yourself.

You enqueue “generate report” from the request, return a job/report id, and poll or push status. Retries and a run history UI come with it. When you need multi-step later (`fetch → render PDF → upload → notify`), you add `step.run` pieces instead of bolting on a second system.

### Also considered

| Option | Why not first |
|---|---|
| **Trigger.dev** | Very close. Especially strong if the PDF step stays long-running on their workers. I’d pick it over Inngest if timeout/compute for Chromium/Puppeteer is the main pain. |
| **BullMQ + Redis** | Fine on “normal” Node (ECS, Cloud Run, a VM). You own retries, DLQ, and a failure UI. More glue before workflows feel good. |
| **Temporal** | Best once workflows are long-lived and branching. Heavy for “PDF off the request path” today. |
| **SQS + workers** | Solid transport. Retries yes; visibility and multi-step are mostly DIY. |
| **Step Functions** | Workflows are first-class if you’re deep in AWS. Awkward Node DX and heavy for one PDF job. |

**Skip for this:** Agenda/Bree/node-cron — thin for retries, failure inspection, and later workflows.

**Pattern either way:** request only creates the job + record; UI watches status; PDF worker is sized for ~40s+ (memory for a headless browser if that’s how you render).

**Inngest** — or **Trigger.dev** if you prefer a more job-runner feel. Same shape either way: durable Node functions, built-in retries, a UI for failed runs, and steps when you grow into multi-step workflows. Fits a normal cloud (ECS/Cloud Run/a long-lived Node process) without you owning a queue stack.

### Why that fits
- Pull PDF generation out of the HTTP path: enqueue/event → return job id → poll or webhook when done.
- Retries and dead-letter style failure visibility come with the product.
- `step.run(...)` (Inngest) / task steps (Trigger) cover the later multi-step work without a second system.

### What else I’d consider

| Option | When it wins | Why I’d skip it first |
|---|---|---|
| **BullMQ + Redis** | You already run Redis and want max control / lowest vendor lock-in | You build dashboards, retry policy UX, and workflow orchestration yourself |
| **Temporal (Cloud)** | Workflows become the product (long sagas, compensations, strict durability) | Heavier for “generate a PDF with retries”; overkill until the workflow surface is real |
| **SQS (+ worker)** | You’re all-in on AWS and want bare infra | Retries yes; “what failed” and multi-step are mostly DIY |
| **Cloud Tasks / Pub/Sub** | Same idea on GCP | Fine transport; weak workflow/observability story alone |

### Practical shape
Request creates a report job → responds immediately with status URL → worker generates the PDF (give it ≥60s headroom; don’t put this on a 10s serverless limit) → store the file + mark success/failure. Start with one function + retries; add steps when you actually have multi-step flows.

If you already have Redis and a small ops appetite, **BullMQ** is the honest DIY pick. If workflows are clearly coming and the team is fine paying for it, go straight to **Temporal Cloud**. For the requirements you listed, managed durable functions (Inngest/Trigger) is the least friction.

Krótka rekomendacja i to, co odrzuciłem po drodze:

**Wybrałbym Inngest** (albo Trigger.dev jako blisko równoważną alternatywę). Oba to platformy do zadań w tle natywne dla Node, dają za darmo dokładnie to, o co pytasz: automatyczne retry z backoffem, dashboard z historią uruchomień i powodem błędu bez własnego UI, a multi-step workflow (`step.run`, `step.sleep`, `step.waitForEvent`) to wbudowany model, nie coś dobudowywane później. Endpoint HTTP w Twoim istniejącym Node, żadnego osobnego klastra do utrzymania.

Co jeszcze rozważałem i dlaczego odpadło:

- **BullMQ + Redis** - najbardziej "boring" opcja, dojrzała, self-hosted, ma Bull Board do podglądu failów i wbudowane retry. Odrzuciłbym jako główny wybór tylko dlatego, że multi-step workflow trzeba by ręcznie sklejać z FlowProducer (parent-child jobs), a to nie jest prawdziwy durable execution - przy pierwszym bardziej złożonym flow (czekanie na zdarzenie zewnętrzne, kroki rozłożone w czasie) zacznie boleć.
- **Temporal** - najsilniejszy pod multi-step (compensations, długie waity, human-in-the-loop), ale to strzelanie z armaty do PDF-a - trzeba utrzymywać serwer/cluster albo płacić za Temporal Cloud. Sensowne, jeśli workflowy faktycznie urosną do czegoś złożonego, nie na start.
- **Graphile Worker** - kusiło, bo Postgres-native (zero nowej infry, jeśli już macie Postgresa), ale observability trzeba by sobie dorobić samemu, a orkiestracja multi-step to w praktyce ręczne łańcuchowanie jobów.
- **AWS SQS + Step Functions** - odpadło, bo piszesz "normal cloud", nie serverless/AWS-specific; to wiązałoby architekturę z jednym vendorem bez wyraźnej potrzeby.

Jeśli wolisz zostać przy czymś self-hosted bez zależności od zewnętrznego SaaS, powiedz - wtedy BullMQ + Redis + Bull Board jest solidnym kompromisem, tylko multi-step trzeba będzie świadomie zaplanować wcześniej.

Rekomendacja: **BullMQ** (kolejka na Redisie) + Bull Board do podglądu zadań. To biblioteka natywna dla Node, dojrzała, z retry/backoff i dead letter "z pudełka", a do przyszłych multi-step flow ma wbudowane Flows (drzewa zależnych jobów), więc nie trzeba dokładać nowej infrastruktury na starcie.

Co jeszcze brałem pod uwagę:
- **Temporal** - to właściwie wzorcowe rozwiązanie pod multi-step workflowy (retry, durable execution, UI pokazujące dokładnie gdzie coś padło), ale to osobny klaster do utrzymania albo płatny Temporal Cloud. Sensowny kolejny krok, jeśli workflowy urosną (długie kroki, human-in-the-loop, kompensacje), ale przedwczesny na sam PDF-generator.
- **pg-boss / Graphile Worker** - kolejka na Postgresie zamiast Redisa, warta rozważenia jeśli już macie Postgresa i wolicie nie dokładać Redisa jako nowej zależności.
- **AWS Step Functions / GCP Workflows** - odpadają, bo wiążą was z konkretnym chmurowym providerem, a wspominałeś o "zwykłej chmurze".
- **Inngest / Trigger.dev** - najszybszy start i gotowy dashboard, ale to zewnętrzne SaaS, więc dochodzi kwestia gdzie fizycznie leci payload (PDF-e) i zależność od kolejnego dostawcy.

Główny kompromis: BullMQ jest lżejszy operacyjnie teraz, ale gdy multi-step workflowy się rozrosną, orkiestrację (retry per krok, kompensacje) będziesz pisać sam - to moment, w którym warto przesiąść się na Temporal. Pasuje to jako plan?

BullMQ (Redis) - dojrzała, ma retry z backoffem, dead-letter/failed jobs do wglądu przez Bull Board, i już teraz obsłuży wasze przyszłe multi-step przez Flows (parent-child joby), więc nie trzeba migrować gdy dojdą workflow. Główny kompromis: Flows to nie pełny durable execution jak Temporal czy Inngest, więc przy bardziej złożonych sagach (retry per-step, sleep/wait, kompensacje) w końcu może być za mało i trzeba będzie się przesiąść.

Co jeszcze rozważałem: Temporal (najlepszy pod multi-step, ale za duży narzut operacyjny na sam start dla jednego zadania jak PDF), Inngest/Trigger.dev (bardzo dobrze pasują właśnie do "retry + widoczność + workflows", ale to nowy serwis/zależność do utrzymania obok Redisa), Graphile Worker (fajne jeśli już macie Postgres i nie chcecie dokładać Redisa, ale słabsza widoczność UI niż Bull Board), oraz czysto chmurowe SQS+worker (odpada, bo "normal cloud" i chcecie uniknąć lock-inu bez wbudowanego dashboardu).

Dla tego przypadku (Node, generowanie PDF poza request-response, retry, widoczność błędów, docelowo multi-step workflows) postawiłbym na **Inngest** (albo jego bliski odpowiednik, Trigger.dev) jako główny kandydat, bo workflow steps z retry per krok i dashboard z historią/błędami to ich core use case, nie dodatek.

Co jeszcze brałem pod uwagę:

- **BullMQ (Redis)** - najbardziej "node-native" opcja, jeśli już macie Redis. Ma retry z backoffem i Bull Board do podglądu failów. Multi-step da się zrobić przez Flows (parent/child jobs), ale to bardziej ręczna orkiestracja niż deklaratywne workflow steps - dobra opcja, jeśli chcecie uniknąć zależności od trzeciego serwisu i macie już ops pod Redis.
- **Surowe SQS / Cloud Tasks** - odrzuciłem jako główną opcję: retry i DLQ są, ale widoczność (co się wysypało i dlaczego) trzeba budować samemu, a multi-step workflow to już osobny byt (Step Functions), więc dokładacie kolejny serwis.
- **Temporal** - najmocniejsze narzędzie pod durable multi-step workflows, ale operacyjnie zbyt ciężkie na start (własny serwer albo Temporal Cloud) w stosunku do tego, co teraz potrzebujecie - trzymałbym z tyłu głowy, gdyby workflows urosły w coś naprawdę złożonego (kompensacje, długie oczekiwania na sygnały zewnętrzne).

Główny trade-off: Inngest/Trigger.dev to zależność od zewnętrznego serwisu (i jego cennika), w zamian dostajecie gotowe retry, dashboard i step-workflow bez budowania tego samemu. BullMQ to więcej własnego kodu i utrzymania, ale zero vendor lock-in.

Rekomendacja: **BullMQ** (kolejka na Redisie) - ma retry z backoffem, listę failed jobs do wglądu (Bull Board jako UI), a jak dojdą multi-step workflow, to BullMQ Flows (parent/child jobs) pociągnie to bez dokładania nowej infry.

Co jeszcze brałem pod uwagę: **Temporal** (najlepszy do docelowych multi-step/durable workflows, wbudowany retry i pełna historia wykonania, ale trzeba hostować własny serwer albo płacić za Temporal Cloud, plus krzywa uczenia "workflow jako kod"), **Inngest** (workflow/step functions pisane w kodzie, ma dashboard i retry - rozsądny kompromis między BullMQ a Temporalem, ale mniej dojrzały w self-hostingu) oraz **pg-boss / Graphile Worker** (jeśli macie już Postgresa, zero nowej infry, ale słabszy tooling do podglądu błędów niż Bull Board).

Główny trade-off: BullMQ jest tańsze i szybsze do wdrożenia pod PDF-y teraz, ale jeśli multi-step workflows to pewniak a nie "może kiedyś", sensowniej wziąć od razu Temporal/Inngest, żeby za pół roku nie przepisywać. Daj znać w którą stronę zmierzacie z tymi workflowami, to dopasuję rekomendację.