Appearance
Tier 2a · Chapter 6: Async Workflows
JS/TS Fullstack (Nuxt) Track · ~30 min read + exercise
A note on sources: The async, reliability, and idempotency principles come from Foundations Chapters 4 and 5 (and the source books); the Nuxt/Nitro deployment-model specifics that reshape how you do background work come from Nitro's documentation and current practice, flagged where relevant.
Why this chapter exists
Foundations Chapter 5 made the case for moving work off the request path, and Chapter 4 covered the reliability patterns that make deferred work safe. Doing this in a Nuxt app has a twist that a standalone backend doesn't face: Nitro deploys to very different runtimes — a long-running Node server, serverless functions, or the edge — and those runtimes have profoundly different stories for background work. On a long-running Node server you can run a persistent queue worker the way any Node backend does; on serverless or edge, there is no persistent process to run a worker in, and the whole approach to backgrounding work changes. So the architectural decision "how do we do async work" in a Nuxt app is entangled with "where does this deploy," in a way that's specific to this stack.
The throughline carries from the foundations but with a Nuxt-shaped caveat: a queue moves work off the request and must be made reliable (retries, idempotency, dead-letter handling) — and in Nuxt, your deployment target dictates how you run the worker at all. The reliability truths are framework- and runtime-independent (at-least-once delivery still mandates idempotency everywhere), but the mechanism for running background work depends heavily on whether you have a persistent process. Getting this wrong means either assuming a worker you can't run (a persistent queue worker on serverless) or doing heavy work inline because you didn't realize you needed an external queue.
What this chapter covers
- Why background work, and the Nitro deployment reality — the same off-the-request-path goal, complicated by where Nitro runs.
- Background work across deployment models — server, serverless, and edge, and what each allows.
- Reliability for async work — the foundations' retries, idempotency, and dead-letter patterns, runtime-independent.
- Choosing an approach — matching the backgrounding mechanism to your deployment.
Why background work, and the Nitro deployment reality
The reason to move work off the request path is the foundations' reason (Chapter 5), unchanged: a Nuxt server route (or an SSR render) that does slow work inline — sending email, processing an upload, calling a slow external API the user doesn't need to wait for — makes the user wait, ties up the request, and (on a Node deployment) risks blocking the event loop (chapter 2). The ticket-resolution example holds: resolve the ticket synchronously (the user needs that), and background the notification, survey, and analytics. That decision is stack-independent.
A cleaner way to model those three reactions is as a single domain event — TicketResolved — emitted once the resolve transaction commits (chapter 5). Instead of the resolve logic explicitly calling notify, survey, and analytics in sequence, it emits the event and the three reactions become independent listeners, each subscribed to it (choreography rather than orchestration — Building Microservices' distinction). The payoff is that adding a fourth reaction (a webhook, a CRM sync) means writing a new listener, not editing the resolve logic — the resolve stays focused on resolving, ignorant of who reacts. Each listener runs as its own backgrounded job, which means each carries the at-least-once delivery property below: a listener will sometimes see the same TicketResolved twice, so every one must be idempotent on its own (sending the survey twice is a bug even if the analytics write is harmless). The event is the seam; idempotent listeners are what make the seam safe. (Flagged: event-emitter/listener wiring and any event-bus library are current-ecosystem specifics; the choreography and idempotency principles are the foundations'.)
What's not stack-independent is how you actually run the backgrounded work, and it comes down to a single question about your deployment: is there a persistent process?
A long-running Node server (Nitro deployed as a Node server, in a container or on a VM) has persistent processes — so you can run a queue worker exactly as any Node backend does (the standard BullMQ-and-workers pattern), a separate long-lived process pulling jobs from a queue. This is the familiar model from any Node service.
A serverless deployment (Nitro deployed to Lambda, Cloud Functions, Vercel/Netlify functions) has no persistent process — each request spins up a short-lived function that handles it and dies. There's nowhere for a long-running worker to live. So background work can't be a worker you run; it has to be a managed external queue (SQS, a cloud task queue) that triggers a function per job, or a scheduled function, or an external job service. The queue and the worker-trigger are infrastructure outside your Nitro app, not a process inside it.
An edge deployment (Nitro on edge runtimes — Cloudflare Workers and similar) is even more constrained: short-lived, limited execution time, often a restricted runtime (not full Node), no persistent process and tight CPU/time budgets. Heavy or long background work essentially cannot happen in the edge function itself; it must be handed off to external infrastructure (a queue, a separate service) almost immediately.
The architectural consequence: decide your deployment model early, because it determines your entire approach to background work. A team that builds assuming a persistent worker and then deploys serverless has built something that can't run; a team on edge that doesn't plan for external job infrastructure has nowhere to put heavy work. This is a foundations-style constraint (Chapter 1): the deployment target is a hard constraint that bounds the async design, and you discover it expensively if you ignore it.
Background work across deployment models
Concretely, here's how the same "background the notification" decision is realized across the three models:
On a Node server: a real queue worker. Jobs go onto a queue (BullMQ on Redis is the common Node choice), and a separate node worker process — run alongside your Nitro server — pulls and processes them. This is the standard Node backend pattern, and it's available because the deployment has persistent processes. You scale workers independently of the web tier, exactly as any Node service does. (This is the model the original backend-oriented approach assumed, and it's still right when you deploy Nitro as a long-running server.)
On serverless: a managed queue plus function triggers. You push a job to a managed queue (SQS, Cloud Tasks, a hosted queue), and the cloud invokes a function per job to process it. There's no worker process you maintain — the queue and the trigger are managed infrastructure, and your "worker" is a function that runs per message and exits. This trades operational simplicity (no worker process to run and scale) for dependence on managed infrastructure and the constraints of per-invocation execution (cold starts, execution time limits).
On edge: hand off fast to external infrastructure. The edge function does the minimum — enqueue to a managed queue or call a job service — and returns; the actual work happens in something that isn't the edge function (a queue-triggered function, a separate service). The edge is too constrained to do the work itself, so its role in async is to dispatch, not to process.
A useful Nitro-specific note: Nitro has built-in primitives that help — scheduled tasks (cron-like, for periodic work) and a storage layer — and some of the lighter background needs (a periodic cleanup, a cache warm) can use these without a full external queue. But for genuine job-queue work (reliable processing of many jobs with retries), you reach for the queue infrastructure appropriate to your deployment, because Nitro itself isn't a job queue. (Flagged: Nitro scheduled tasks, storage, and deployment-preset behavior are current-ecosystem specifics from Nitro's docs.)
Reliability for async work
Here the foundations reassert themselves unchanged, because reliability is a property of the queue and the work, not of the runtime: whatever your deployment, the moment work is deferred through a queue, the Chapter 4 patterns apply, and they apply identically to a Node-server worker, a serverless function trigger, and an edge handoff.
Retries with backoff for transient failures — the job failed because a downstream blipped, so retry with exponential backoff and jitter (Chapter 4) to recover without a retry storm. Every queue mechanism supports this; the values are your decision.
At-least-once delivery makes idempotency mandatory — the framework-and-runtime-independent fact, exactly as in any async system: queues (BullMQ, SQS, all of them) deliver at-least-once, so a job will sometimes run more than once (a worker or function dies after doing the work but before acknowledging), and the handler must be safe when it does. A notification job must not send twice; a charge must not double. This is the keystone, and it's true on a Node worker, a serverless trigger, and an edge handoff alike — because it comes from the delivery model, which all queues share. Write every job idempotent: naturally (set a state) or with an idempotency key / processed-marker recorded with the side effect.
Dead-letter handling — jobs that exhaust retries go to a dead-letter queue (or the managed queue's DLQ equivalent), so unprocessable work is visible and recoverable rather than silently lost, and the DLQ must be monitored (the ops chapter) or it's a black hole. Replaying dead-lettered jobs re-runs them, so the same idempotency makes replay safe.
The reliability chain is identical to any async system because it's about the queue and the work: retries handle transient failures, idempotency makes retries and at-least-once delivery and replays safe, dead-letter handling catches the unprocessable. What changes across deployments is where the handler runs (a worker process, a triggered function, a handoff target) — not what makes it reliable. So you reason about reliability with the foundations' patterns regardless of deployment, and reason about the mechanism with the deployment model.
Choosing an approach
Pulling it together into a decision:
First, know your deployment model, because it bounds everything (the foundations' constraint-first thinking). Node server → you can run real workers. Serverless → managed queue + function triggers. Edge → dispatch to external infrastructure. This is the first question, not an afterthought, because building against the wrong model produces something that can't run.
Background the work that should be backgrounded — the off-the-request-path decision from Foundations Chapter 5, unchanged: anything the user doesn't need to wait for, anything slow, anything that shouldn't share the request's fate or block the event loop. The decision of what to background is stack-independent; only the how depends on deployment.
Apply the reliability patterns regardless — retries, idempotency (mandatory, at-least-once), dead-letter with monitoring — because they're properties of deferred work, not of the runtime. Whatever runs your jobs, they need these.
Use Nitro's lighter primitives for lighter needs — scheduled tasks for periodic work, the storage layer for simple state — and reserve full external queue infrastructure for genuine job-processing, matched to your deployment.
The honest summary for a fullstack Nuxt team: the architecture of async work is the foundations' architecture (background the right things, make them reliable), and the mechanism is a deployment decision you must make deliberately and early, because Nitro's flexibility to deploy as server, serverless, or edge means there's no single answer to "how do we run background jobs" — there's the answer your deployment allows.
That's async in Nuxt: the off-the-request-path goal and the reliability patterns (retries, mandatory idempotency, monitored dead-letters) are the foundations' and don't change; what changes is that Nitro's deployment target — server, serverless, or edge — dictates how you run background work at all, so the deployment model is a constraint you decide early and design the async approach around.
Practice
Budget about ninety minutes.
Exercise 1: Identify the deployment constraint (20 min)
For a Nuxt app you work on (or plan), determine the deployment model — long-running Node server, serverless, or edge — and what it allows for background work. Then find work currently done inline in a request that should be backgrounded, and note whether your deployment can run the worker you'd need, or whether you'd need managed queue infrastructure.
Exercise 2: Make a job idempotent (35 min)
Take a background job (real or planned) with a side effect. Given at-least-once delivery — true regardless of deployment — trace how it could run twice harmfully, and redesign the handler to be safe (a durable guard or idempotency key recorded with the side effect). Note that this is the same requirement whether the job runs on a Node worker, a serverless trigger, or an edge handoff.
If you use an AI assistant to draft the idempotency guard, interrogate the race under concurrent redelivery — can two copies both pass the "already done?" check before either records completion? Closing that (a transaction or unique constraint) is the easy-to-miss part.
Exercise 3: Design the mechanism for your deployment (35 min)
For that job, design the actual mechanism given your deployment model: a BullMQ worker (Node server), a managed queue + function trigger (serverless), or a dispatch-to-external (edge). Include the retry policy and where dead-lettered jobs go and how they're monitored. Note how the mechanism would differ if you changed deployment models — proving the architecture is constant and the mechanism is deployment-bound.
Deliverable
A short async design for one Nuxt workflow: the deployment model and what it allows, what's backgrounded and why, the mechanism appropriate to that deployment, and the reliability story (retries, idempotency with its at-least-once justification, monitored dead-letters) — with a note on how the mechanism would change under a different deployment.
Check yourself
- Explain why the deployment model (server/serverless/edge) determines how you run background work in Nuxt.
- Describe how the same "background this" decision is realized on a Node server vs. serverless vs. edge.
- Explain why at-least-once delivery makes idempotency mandatory regardless of deployment.
- Explain what stays constant (the reliability architecture) vs. what changes (the mechanism) across deployments.
What a strong answer demonstrates: a strong async design names the deployment model first (it bounds everything), then separates the constant from the variable — the reliability architecture (retries, mandatory idempotency, monitored dead-letters) holds everywhere, while the mechanism (real worker / managed queue + trigger / edge handoff) follows the deployment. The clearest signal of understanding is justifying idempotency from at-least-once delivery and closing the redelivery race, then noting how only the mechanism would change under a different target.
Going deeper (optional)
- Software Architecture: The Hard Parts — the distributed-workflow and saga chapters, for keeping multi-step async workflows consistent (the capstone returns to this).
- Building Microservices (Newman), the workflow chapter, for orchestration vs. choreography. Nitro's deployment and tasks documentation for the runtime specifics. (Flagged: Nitro deployment presets, scheduled tasks, and storage are current-ecosystem specifics; the async/reliability principles are from the foundations.)
- Primary sources (the theory beneath choreographed, idempotent background work): Hector Garcia-Molina & Kenneth Salem, "Sagas" (ACM SIGMOD, 1987) — the original break-a-long-transaction-into-compensable-steps idea behind multi-step async workflows. And Pat Helland, "Life Beyond Distributed Transactions: an Apostate's Opinion" (CIDR 2007) — the influential case for coordinating with messages and idempotent activities instead of distributed transactions, which is exactly why at-least-once delivery makes idempotent job handlers mandatory.
Key takeaways
- The decision to move work off the request path and the reliability patterns (retries, idempotency, dead-letter handling) are the foundations' and are runtime-independent.
- But in Nuxt, Nitro's deployment target dictates how you run background work: a Node server allows real queue workers; serverless needs a managed queue + function triggers (no persistent worker); edge must dispatch to external infrastructure.
- At-least-once delivery makes idempotency mandatory on every deployment — jobs run more than once whether on a worker, a trigger, or a handoff.
- Decide the deployment model early (a foundations-style constraint) and design the async mechanism around it; the architecture stays constant, the mechanism is deployment-bound. Use Nitro's scheduled tasks/storage for lighter needs.
Next: Testing the Fullstack — testing both halves of a Nuxt app: components and composables, server routes, and end-to-end across the boundary.