Background Jobs in Node.js: BullMQ vs Agenda

Background jobs keep slow work out of requests

Most production applications need work that should not happen inside the main request-response path. Sending emails, processing images, syncing data, generating reports, charging invoices, and retrying webhooks are all common background jobs. In Node.js, BullMQ and Agenda are two well-known options, but they use different storage backends and fit different operational preferences.

BullMQ is built around Redis. It provides queues, workers, delayed jobs, retries, priorities, repeatable jobs, and event handling. Redis is fast, widely used, and well suited to queue-like workloads. If your team already runs Redis for caching or rate limiting, BullMQ may fit naturally. It is often a strong choice for high-volume job processing where throughput and queue semantics matter.

Agenda uses MongoDB persistence

Agenda uses MongoDB for persistence. It stores jobs in a MongoDB collection and provides scheduling, recurring jobs, priorities, locking, and retries. For teams already using MongoDB as their primary database, Agenda can be operationally convenient because it avoids adding Redis. It can be a good fit for scheduled business tasks, periodic processing, and applications where job volume is moderate.

The storage backend affects reliability and operations. Redis is excellent for fast queue operations, but teams must configure persistence, memory limits, eviction policies, and monitoring carefully. A Redis instance used for background jobs should not casually evict queue data under memory pressure. MongoDB persistence may feel more familiar to document-database teams, but job locking and polling behavior need attention as worker counts grow.

• Use BullMQ when Redis is acceptable and queue throughput matters.
• Use Agenda when MongoDB persistence fits the existing stack.
• Design every retryable job to be idempotent.
• Monitor queue depth, failure rate, job duration, and worker health.

Retries and scheduling determine reliability

Retries are central to background processing. A good job system should support retry counts, backoff strategies, failure tracking, and dead-letter handling or equivalent review workflows. Retrying immediately can overload a failing dependency. Exponential backoff with jitter is often safer. For payments, emails, and external APIs, jobs should be idempotent so a retry does not create duplicate side effects.

Scheduling needs vary. If you need simple recurring tasks, both tools can help. If you need heavy queue throughput, many worker types, and operational visibility around queue depth and processing rates, BullMQ often feels more queue-native. If you need jobs stored alongside business data in MongoDB and prefer a document-based scheduling model, Agenda may be simpler.

Operations matter more than the happy path

Scaling background workers requires more than installing a library. Workers should handle graceful shutdown so active jobs are not abandoned during deploys. Long-running jobs should report progress or checkpoint work. Job payloads should stay small; store large data in a database or object storage and pass references through the queue. This keeps the job system fast and easier to debug.

Observability is essential. Track queue depth, job duration, failure rates, retry counts, and worker health. A background job failure may not be visible to users immediately, but it can break billing, notifications, or data freshness. Add alerts for stuck queues and repeated failures. Provide an administrative path to inspect and replay failed jobs when appropriate.

Choose BullMQ when Redis is acceptable and you need a strong queue system with high throughput and rich job controls. Choose Agenda when MongoDB persistence and simple scheduling align better with your stack. Whichever tool you choose, design jobs to be idempotent, observable, retry-safe, and operationally boring. Background work is only successful when it keeps running after the first happy-path demo.