Why I Used BullMQ + Redis for Background Jobs in My NestJS Application — and When I Wouldn't

Sun, 04 Oct 2026 15:45:42 +0000

While working on Waitless, a real-time queue management platform, I came across a backend problem that looked simple at first:

A customer reaches the front of the queue, and the system needs to send notifications to other customers.

The first instinct could be to simply send the email inside the HTTP request.

But once I looked at the problem as a backend architecture problem rather than just an implementation task, I realized that sending the email and handling the user's request are two different workloads.

That led me to BullMQ + Redis.

The interesting part wasn't learning the API. The interesting part was understanding why this architecture made sense, what Redis was actually doing, and when I would choose something else instead.

The problem in Waitless

Waitless allows customers to join a digital queue and track their position without creating an account.

When one customer is called, another customer may need to receive a notification such as:

“It's your turn.”
“You're almost next.”

I already had the queue state stored in PostgreSQL. The question was:

Should the API send the email immediately, or should it create background work?

A synchronous approach could look like this:

HTTP request
     ↓
NestJS
     ↓
PostgreSQL
     ↓
Send email
     ↓
HTTP response

The problem is that sending an email depends on an external service.

If that service is slow or temporarily unavailable, my API request is affected.

I don't necessarily need the email to be completed before responding to the user.

What I actually need is:

“Remember that this email has to be sent, and process it separately.”

That is exactly the kind of problem a job queue is designed to solve.

Introducing BullMQ

BullMQ provides a job queue abstraction for Node.js applications.

Instead of doing the work immediately, the application creates a job:

Application
     ↓
   Queue
     ↓
    Job
     ↓
   Worker
     ↓
 Actual work

The application that creates the job is the producer.

The worker that processes the job is the consumer/worker.

This gives me a clean separation between:

Creating work

and:

Executing work

That separation becomes particularly useful when the work is slow, retryable, delayed, or needs to be processed independently from the HTTP request.

Where Redis comes in

One thing I initially had to clarify for myself was the relationship between BullMQ and Redis.

They are not the same thing.

A simplified mental model is:

NestJS
   ↓
BullMQ
   ↓
Redis

BullMQ is the queue system.

Redis is the backend that BullMQ uses to store and coordinate queue-related state.

In my NestJS application, I configure the connection like this:

BullModule.forRoot({
  connection: {
    host: 'localhost',
    port: 6379,
  },
});

Port 6379 is Redis's default port, so this configuration tells BullMQ which Redis instance to connect to.

The important distinction is:

BullMQ is not “running on port 6379.”
BullMQ is connecting to the Redis server running there.

Creating a notification job

In Waitless, I inject the notification queue into my service:

@InjectQueue('notifications')
private notifQueue: Queue

Now I can add jobs to that queue.

For example:

if (next.email) {
  await this.notifQueue.add('your-turn-now', {
    email: next.email,
    name: next.name,
    queueName: queue.name,
  });
}

This does not mean:

“Send the email now.”

It means:

“Create a job called your-turn-now and put it into the notifications queue.”

The payload contains the information the worker will need later.

Conceptually:

NestJS
   ↓
notifQueue.add(...)
   ↓
BullMQ
   ↓
Redis
   ↓
notifications queue
   ↓
your-turn-now job

The actual email is the responsibility of the worker.

Delayed jobs

One of the features I needed was delayed notification.

If another customer is second in line, I want to notify them shortly before their turn.

My implementation looks like this:

const secondInLine =
  await this.entryRepo.findSecondWaiting(queueId, next.id);

if (secondInLine?.email) {
  await this.notifQueue.add(
    'your-turn-soon',
    {
      email: secondInLine.email,
      name: secondInLine.name,
      position: 2,
      queueName: queue.name,
      trackingUrl: `http://localhost:3000/track/${secondInLine.token}`,
    },
    {
      delay: 30_000,
    },
  );
}

The important part is:

{ delay: 30_000 }

The job doesn't need to be processed immediately.

The architecture becomes:

Customer becomes second in line
            ↓
      Create BullMQ job
            ↓
       Delayed job
            ↓
          30 sec
            ↓
        Worker picks it up
            ↓
        Send notification

This is much more reliable than simply doing:

setTimeout(() => {
  sendEmail();
}, 30_000);

A timer belongs to the application process itself. A queue gives the work an explicit lifecycle outside the original request.

Why not just use PostgreSQL for the queue?

This was one of the more interesting questions I explored.

At first glance, PostgreSQL looks like a perfectly reasonable choice.

I could create a table such as:

jobs
-------------------
id
type
payload
status
created_at
processed_at

and continuously insert and delete jobs.

The problem is that the queue workload has different characteristics from my core business data.

My PostgreSQL database is responsible for things such as:

businesses
queues
customers
queue entries
relationships
transactions

Those are my core relational business data.

The queue workload is different:

job created
job becomes active
job succeeds
job fails
job retries
job is removed

This is a high-churn operational workload.

With PostgreSQL's MVCC model, repeatedly inserting and deleting rows creates dead tuples that later have to be cleaned up by VACUUM.

That doesn't mean PostgreSQL cannot implement queues. It absolutely can.

The real architectural question is:

Do I want the queue workload competing with my transactional business workload inside the same database?

For a small application, the answer might be yes.

For a higher-throughput system, separating those workloads can become valuable.

Why Redis made sense for my queue

Redis is designed around very fast operations on in-memory data structures.

That makes it a natural fit for workloads such as:

caching
counters
temporary state
queues
rate limiting
pub/sub
fast lookups

For my notification queue, the important characteristics were:

Asynchronous
High frequency
Short-lived job state
Low latency
Retries
Delayed execution
Worker concurrency

So instead of:

PostgreSQL
   ├── business data
   └── queue workload

I could separate them:

PostgreSQL
     ↓
Business state


Redis
     ↓
BullMQ
     ↓
Background jobs
     ↓
Workers

That separation was more important to me than simply saying:

“Redis is faster.”

What I learned about workload-driven architecture

This changed the way I think about databases.

The question shouldn't simply be:

Which database is better?

A better question is:

What workload am I dealing with?

For example:

Requirement	Possible choice
Relational transactional data	PostgreSQL
Very fast temporary state	Redis
Background jobs with retries	BullMQ + Redis
Document-oriented event data	MongoDB
Large event streams and replay	Kafka
Small simple background jobs	PostgreSQL or a scheduler
Managed cloud queue	SQS or similar service

These aren't absolute rules.

They are starting points for architectural reasoning.

BullMQ gives me more than a queue

Another thing I learned is that the real value of a job system is not just putting something into a list.

BullMQ provides concepts such as:

Jobs
Workers
Retries
Backoff
Delayed jobs
Concurrency
Rate limiting
Failed jobs
Job lifecycle

That matters because real systems fail.

For example:

Worker
   ↓
Send email
   ↓
Email provider unavailable
   ↓
Job fails
   ↓
Retry
   ↓
Worker tries again

The system can therefore treat background work as something with a lifecycle instead of a simple function call.

But there is an important failure model

A queue doesn't automatically mean:

“The job runs exactly once.”

A worker can crash.

A network call can time out.

A job can be retried.

The same operation may therefore be executed more than once.

That means job handlers should often be designed with idempotency in mind.

For example, a payment operation is much more dangerous to retry blindly than sending a harmless notification.

This was an important lesson for me:

Using a queue changes the failure model of the application.

You have to think about retries, duplicates, timeouts, and partial failures.

Could I use BullMQ without Redis?

Interestingly, yes.

Modern BullMQ also provides a PostgreSQL backend.

That means the conceptual architecture can also be:

NestJS
   ↓
BullMQ
   ↓
PostgreSQL

This can make sense when I want to keep the infrastructure simpler and the queue workload is moderate.

But there is a trade-off.

Using PostgreSQL for both workloads means:

PostgreSQL
 ├── transactional business data
 └── queue workload

So the queue and business operations share database resources.

That can be perfectly reasonable for a smaller application.

For a system with large queue throughput, isolating the queue workload may become more attractive.

This is why there isn't one universally correct answer.

When I would NOT use BullMQ + Redis

This was probably the most useful part of the exercise.

I don't want to add Redis and BullMQ just because they are popular technologies.

For something like:

const result = calculateTax(data);

there is no reason to create a queue.

If a task takes a few milliseconds and the user needs the result immediately, synchronous processing is simpler.

I also might avoid BullMQ for a very small scheduled task:

Every day at 08:00
Generate one report

A simple scheduler could be enough.

And if the application already uses PostgreSQL and has only a small number of background jobs, a PostgreSQL-backed solution may be simpler than adding another infrastructure component.

The lesson is:

Don't introduce distributed infrastructure without a workload that justifies it.

The decision I now make before choosing a queue

Instead of thinking:

“Should I use BullMQ?”

I ask:

1. Does this work need to happen asynchronously?

If yes, continue.

2. Does it need retries or failure recovery?

If yes, a real job system becomes more useful.

3. Does it need delayed execution?

For example:

Do this after 30 seconds.

4. Does it need multiple workers or concurrency?

For example:

Queue
 ├── Worker 1
 ├── Worker 2
 └── Worker 3

5. Does the workload justify another infrastructure component?

This is the trade-off question.

Only after answering those questions would I choose the technology.

My current mental model

The biggest thing I learned from implementing this feature is that architecture is less about memorizing technologies and more about matching workloads to the right tools.

For Waitless, my current architecture can be thought of as:

                    Waitless
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
     PostgreSQL      Redis       MongoDB
          │            │            │
   business state    jobs      event history
                    BullMQ
                       │
                    Workers
                       │
                   Email/API

PostgreSQL answers:

What is the current business state?

Redis + BullMQ answers:

What work needs to be processed asynchronously?

MongoDB answers:

What happened in the event history, and what can I derive from those events?

The important thing is not that I used three technologies.

The important thing is that each technology was chosen for a different workload.

Final takeaway

The best lesson I took from this wasn't actually “how to use BullMQ.”

It was this:

Before choosing a technology, understand the workload.

Ask:

What problem am I solving?
What are the access patterns?
What guarantees do I need?
How does the system fail?
What are the trade-offs?
What simpler alternative could work?

Once I started thinking this way, Redis, BullMQ, PostgreSQL, MongoDB and other technologies stopped looking like isolated tools.

They became different tools for different engineering problems.

And that is the mindset I want to continue developing as I work toward designing larger backend systems.

Coder Legion - Recent posts tagged bullmq

Why I Used BullMQ + Redis for Background Jobs in My NestJS Application — and When I Wouldn't

The problem in Waitless

Introducing BullMQ

Where Redis comes in

Creating a notification job

Delayed jobs

Why not just use PostgreSQL for the queue?

Why Redis made sense for my queue

What I learned about workload-driven architecture

BullMQ gives me more than a queue

But there is an important failure model

Could I use BullMQ without Redis?

When I would NOT use BullMQ + Redis

The decision I now make before choosing a queue

1. Does this work need to happen asynchronously?

2. Does it need retries or failure recovery?

3. Does it need delayed execution?

4. Does it need multiple workers or concurrency?

5. Does the workload justify another infrastructure component?

My current mental model

Final takeaway