What is background job processing?
Background jobs are tasks that run outside the normal request/response cycle. When a user triggers an action — uploading a file, completing a purchase, signing up — your API responds immediately without waiting for every downstream task to finish. The heavy work happens asynchronously, in the background.
There are two flavours: event-triggered jobs (run when something happens — send a welcome email when a user registers, generate a PDF when an invoice is created) and scheduled jobs (run at fixed times — charge subscription renewals at midnight, send a weekly digest every Monday morning, clean up expired sessions every hour).
Without this infrastructure, long-running tasks either slow down your API responses or simply don't get done reliably.
When does your app need it?
- Sending transactional emails or SMS (should never block an API response)
- Processing uploaded files — resizing images, extracting text from PDFs, transcoding video
- Generating reports or exports that take more than a second or two
- Charging subscription renewals on a schedule
- Syncing data with third-party services (CRM, accounting, analytics)
- Cleaning up expired records, sending reminder notifications, or triggering time-based workflows
How much does it cost?
Adding background job processing typically adds 5–11 hours of development — roughly $1,000–$2,000 AUD.
Lower end: A simple job queue for one or two task types (e.g. send email, process uploaded image) with basic retry logic. BullMQ with Redis or a managed service like Trigger.dev keeps this straightforward.
Higher end: Multiple queues with different priority levels, concurrency controls, complex scheduling rules, dead-letter queues for permanently failed jobs, a monitoring dashboard (Bull Board or similar), alerting on queue depth, and job chaining (the output of one job triggers the next).
How it's typically built
The most common Node.js stack is BullMQ with a Redis instance. BullMQ handles queue management, concurrency, retries, and scheduling. Workers are separate processes that dequeue and execute jobs. Redis stores the job state.
For teams on AWS, SQS (Simple Queue Service) is a managed alternative — no Redis to operate, automatic scaling, and built-in dead-letter queues. For managed solutions with minimal infrastructure overhead, Inngest and Trigger.dev provide a developer-friendly layer on top, with built-in dashboards and local development tooling.
Scheduled jobs (cron-style) are typically implemented with node-cron for simple cases, or handled natively by the job queue framework. In serverless environments, cloud provider scheduled functions (AWS EventBridge, Vercel Cron) are used instead.
Questions to ask your developer
- Which framework are you using? BullMQ requires a Redis instance; some teams prefer a fully managed option to avoid the ops overhead.
- What happens when a job fails? Understand the retry policy and what alerts fire when jobs end up in the dead-letter queue.
- Are any jobs time-critical? High-priority queues process ahead of bulk tasks — important if sending payment confirmations alongside low-priority digests.
- How will you monitor queue health? A backed-up queue is an ops problem — you want visibility before users notice.
- Are scheduled jobs in UTC or local time? Daylight saving can cause subtle bugs in time-based logic.
See also: Real-time updates · Transactional email · App cost calculator