Background Job Queues: Why 'Just Do It in the Request' Doesn't Scale

Sending a confirmation email, resizing an uploaded image, or generating a report often starts life as a few lines of code running directly inside a request handler — and it works fine, right up until that email service is slow one day and every user signing up has to sit and wait for it, or the app times out entirely.

Why doing this synchronously breaks down

A request handler doing extra, slow work on every request means your app's responsiveness is only as reliable as the slowest external service it happens to call along the way. One flaky dependency, and suddenly your entire signup flow feels broken, even though the core signup itself worked fine.

What a job queue actually solves

• The request handler does the minimum necessary work, queues the slow task, and responds to the user immediately — the user isn't waiting on your email provider's response time.
• Failed jobs can retry automatically without the user ever knowing something briefly went wrong, in the same spirit as reliable webhook handling.
• Work can be processed at a controlled rate, protecting downstream services from being overwhelmed by a sudden burst of requests.
• Visibility into what's queued, what's processing, and what's failed, instead of errors buried silently inside a request that already returned successfully to the user.

When it's worth adding this

The moment a request handler is doing anything beyond the core, fast, essential operation — sending an email, calling a third-party API, generating a file — that's usually the signal it belongs in a queue instead, a pattern that fits naturally into the broader production discipline we described in Next.js in production.

A user shouldn't have to wait for your email provider to be fast. A queue is what makes your app's responsiveness independent of everyone else's.

This is one of the more common architectural gaps we find in early-stage products that grew past their original, simpler assumptions — worth adding before a slow external dependency becomes a visible outage instead of a background retry.