bullmq-job-architect

Create a Queue instance with its own ioredis connection, define defaultJobOptions with attempts and exponential backoff, and add jobs via queue.add. Each job type gets its own queue, and Queue, Worker, and QueueEvents each need separate Redis connections to avoid deadlocks.

Configure attempts with exponential backoff in defaultJobOptions, then listen to the worker's failed event. When attemptsMade reaches the configured attempts, move the job to a dedicated dead letter queue that stores the original job data, error message, and stack for later inspection and replay.

Use the formula concurrency = ceil(rate_limit_per_sec × avg_job_duration_sec × 1.2 buffer). For CPU-bound jobs like PDF generation, use os.cpus().length instead. Transactional email workers typically run 20-50 concurrent jobs, while cron workers use concurrency of 1.

BullMQ deadlocks when Queue, Worker, and QueueEvents share a single ioredis connection, or when the connection lacks required settings. Create a separate connection per role and set maxRetriesPerRequest to null and enableReadyCheck to false in the Redis options.

Add a job with a repeat option containing a cron pattern, such as '0 2 * * *' for daily at 2am UTC. Always set a stable jobId so the recurring job registers only once, and use removeRepeatable with the same pattern to unregister it.

Yes, BullMQ's FlowProducer supports parent-child job trees where children complete before parents run. You define the tree with nested children arrays across different queues, and BullMQ processes it bottom-up, such as validate then generate PDF then send email.