Background job queue
A waiting list of work that runs outside the user's request, so slow or risky jobs such as migrations and bulk email don't hold up the screen.
Updated October 2026 · with examples from our own builds
What does background job queue mean in practice?
When a task takes longer than a page load, such as sending a batch of emails, copying files between clouds or filing a document with a government portal, the app puts a job on a queue and a separate worker picks it up. The user gets an answer straight away while the work carries on in the background.
Queues decide what happens when things go wrong. A good one survives a server restart, retries failures sensibly and never runs the same job twice; a bad one loses work silently or sends a customer the same email three times.
They also need somewhere to live, such as Redis or the database, plus a view of what is stuck and a rule for how many retries happen before a person is told.
Background job queue at a glance
- Use for
- Slow, retryable or scheduled work
- Must survive
- Restarts, crashes and duplicate messages
- Watch
- Jobs stuck or failing repeatedly
Where has background job queue come up in our builds?
Migrations run on a MongoDB-backed queue. A worker claims a job with one atomic update that sets a 90-second lease and renews it every 30 seconds; if the process dies, the lease expires and the next claim resumes from the last key that copied cleanly.
Email sends run on a separate BullMQ worker on Redis. Each send has a unique key per enrolment and step, and the sender claims a job atomically, so a duplicated queue message cannot send an email twice.
Common questions about background job queue
What happens to queued work if the server restarts?
With a lease-based queue, nothing is lost: a job whose worker stops becomes claimable again once its lease expires and resumes from its last checkpoint. Ask your team how long that takes and where the checkpoint is kept.
Do I need Redis to run a job queue?
Not always. Storafleet's migration queue runs on MongoDB, which the product already used, while LoudMouth uses BullMQ on Redis for high-volume sends. The choice follows volume and what the stack already runs.
Related terms
Sources
Planning a product and not sure where background job queue fits? Ask us, or browse all 116 terms in the glossary.