Background Jobs & Queues for Builders
Every product eventually has work that is too slow to run inside a request: sending email, processing video, calling an LLM, generating a PDF. This course teaches you how to move that work into background jobs — what a queue actually is, how to choose between Redis-based and managed providers, how to handle retries and failures safely, and how to run jobs in production without losing data or your users' trust.
What you'll learn
Course outline
Free — no account needed
Why You Need a Job Queue
The moment a request handler starts doing slow work, you have a queue-shaped problem
How Job Queues Work
Producers, brokers, and workers — the three pieces of every queue system
Your First Background Job
Set up a managed queue and trigger a real job in under 10 minutes
Full course — $59 one-time
Choosing a Queue: Redis-Based vs Managed
BullMQ, Inngest, Trigger.dev, and SQS solve the same problem at different points on the control/convenience tradeoff
Retries, Backoff, and Idempotency
Jobs will fail — the difference between a resilient system and a dangerous one is what happens next
Scheduling & Cron Jobs
Delayed jobs, recurring jobs, and the gotchas of running cron in a serverless world
Observability & Dead-Letter Queues
You cannot fix a job failure you never see — visibility is the feature, not an afterthought
The Production Background Jobs Checklist
Concurrency limits, rate limiting, graceful shutdown — the details that separate a demo from a production system
Get the full course
8 lessons — from your first queue to production-grade retries, scheduling, and observability.
About this course
Background jobs and message queues let an application move slow work — sending email, processing video, calling an AI model, generating a report — out of the request/response cycle, so users get a fast response while the heavy lifting happens separately. Learning how queues work means understanding the producer/broker/worker model that every queue tool (BullMQ, Inngest, Trigger.dev, AWS SQS) is built from, and the failure-handling patterns — retries, exponential backoff, idempotency — that keep a queue safe to use for things like billing and transactional email.
This course is for backend and full-stack developers who have hit the point where a request handler is doing too much synchronous work. After completing it you will be able to choose between Redis-based and managed queue platforms, set up a real background job from scratch, design idempotent jobs that are safe to retry, schedule delayed and recurring jobs, and ship a production-ready worker with proper concurrency limits, rate limiting, and observability.
Frequently asked questions
Do I need Redis to use background jobs?
No. Redis-based queues like BullMQ require you to run and manage a Redis instance, which gives you full control and very low per-job cost at scale. Managed platforms like Inngest, Trigger.dev, and AWS SQS handle the broker for you — no Redis to provision — at the cost of usually being priced per job or per execution. Most small-to-mid-size teams start with a managed platform and only move to self-hosted Redis once volume or cost makes it worthwhile.
What is the difference between a background job and just using setTimeout or an async function?
A detached async call or setTimeout disappears the moment your server process restarts or redeploys — there is no broker holding the job, so any in-flight work is silently lost. A real queue persists the job in a broker (Redis, a managed service, or a database table) until a worker confirms it is complete, and can retry it automatically if it fails. If the work matters — sending an invoice, processing a payment — it needs a real queue, not a fire-and-forget call.
What does "idempotent" mean for a background job, and why does it matter?
An idempotent job produces the same end result whether it runs once or several times. This matters because queues retry failed jobs by design — if a "charge the customer" job times out after the charge actually succeeded, a naive retry charges the customer twice. Idempotency is usually implemented with an idempotency key (many payment providers support this natively) or a "has this already happened?" check before acting.
How do I run cron jobs if I deploy to a serverless platform like Vercel?
Serverless functions only run in response to a request — there is no long-running process waiting to fire at a scheduled time. You need either a platform with native cron support (Inngest functions, Vercel Cron, GitHub Actions scheduled workflows) or an external scheduler that pings an API route at the right time (QStash, an external cron service). Whichever you choose, make the scheduled job idempotent in case it ever fires twice in the same window.
How many retries should a failed job get?
Most production systems use 3–5 retries with exponential backoff (e.g. wait 1s, then 2s, then 4s, then 8s) before sending a job to a dead-letter queue for a human to investigate. Retrying indefinitely wastes resources on permanently broken jobs (e.g. invalid input), while retrying too few times can drop jobs that would have succeeded on a transient failure. Distinguish retryable errors (timeouts, rate limits, 5xx responses) from permanent ones (validation failures, 4xx responses) and only retry the former.