BullMQ
Search…
What is BullMQ
Quick Start
API Reference
Changelog
Guide
Introduction
Connections
Queues
Workers
Jobs
Flows
Metrics
Rate limiting
Retrying failing jobs
Returning job data
Events
QueueScheduler
Architecture
Patterns
Manually processing jobs
Producer - Consumer
Named Processor
Flows
Real time updates
Sender - Receiver
Working with batches
Idempotent jobs
Throttle jobs
Process Step Jobs
Failing fast when Redis is down
BullMQ Pro
Introduction
Install
Observables
Groups
API Reference
Changelog
Bull
Introduction
Install
Quick Guide
Important Notes
Reference
Patterns
Persistent connections
Message queue
Returning Job Completions
Reusing Redis Connections
Redis cluster
Custom backoff strategy
Debugging
Manually fetching jobs
Bull 3.x Migration
Compatibility class
Migration
Powered By GitBook
Returning Job Completions
A common pattern is where you have a cluster of queue processors that just process jobs as fast as they can, and some other services that need to take the result of these processors and do something with it, maybe storing results in a database.
The most robust and scalable way to accomplish this is by combining the standard job queue with the message queue pattern: a service sends jobs to the cluster just by opening a job queue and adding jobs to it, and the cluster will start processing as fast as it can. Everytime a job gets completed in the cluster a message is sent to a results message queue with the result data, and this queue is listened by some other service that stores the results in a database.
​
Previous
Message queue
Next
Reusing Redis Connections
Last modified 4mo ago
Copy link