Implement Robust BullMQ Job Queues

This skill is a BullMQ specialist for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications, grounded in eight core principles: jobs are fire-and-forget from the producer side, always set explicit job options since defaults rarely fit, idempotency is the job's own responsibility since jobs may run more than once, exponential backoff beats linear to prevent thundering herds, dead letter queues are not optional, concurrency limits should start conservative to protect downstream services, job data should carry IDs rather than full payloads, and graceful shutdown (handling SIGTERM properly) prevents orphaned jobs. A basic production queue setup shares one ioredis connection (with maxRetriesPerRequest: null required for BullMQ), configures a Queue with default job options (3 attempts, exponential backoff, bounded removeOnComplete/removeOnFail counts), and a Worker with a concurrency limit and a rate limiter (e.g. 100 jobs per minute), plus a failed event handler. Delayed and scheduled jobs cover a one-time delay in milliseconds and a cron-pattern repeat with an explicit timezone (and how to remove a repeatable job by matching its exact pattern/timezone). Job flows use FlowProducer to express parent-child dependencies, where a parent job (e.g. process-order) waits for multiple named child jobs (validate inventory, charge payment, notify warehouse) to complete first. Graceful shutdown pauses the worker (stop accepting new jobs), closes it (waiting for in-flight jobs), then closes the queue connection, wired to both SIGTERM and SIGINT. A Bull Board dashboard integration (@bull-board/api/@bull-board/express) mounts a visual queue-monitoring UI at an admin path. Ten validation checks encode common defects with severity levels: missing maxRetriesPerRequest: null (ERROR - causes workers to stop on Redis connection issues), missing stalled/failed event handlers (WARNING), missing graceful shutdown handling (WARNING - orphaned jobs on deploy), awaiting queue.add in a request handler instead of fire-and-forget (INFO), large inline job payloads instead of IDs (WARNING), missing job timeouts (INFO), retries without a backoff strategy (WARNING - thundering herd risk), repeatable jobs without an explicit timezone (WARNING - DST drift), and high worker concurrency without downstream capacity checks (INFO). The skill explicitly delegates out-of-scope work: Redis infrastructure/cluster tuning to a redis-specialist, serverless/no-Redis queues to upstash-qstash, complex workflow orchestration (sagas, long-running compensation) to temporal-craftsman, event sourcing/CQRS to event-architect, and email delivery specifics to email-systems. Named workflow stacks combine it with those companion skills for an email queue pipeline, general background processing, an AI processing pipeline with dependent job stages, and scheduled-task pipelines.

Use this skill when a user mentions or implies BullMQ, Bull queues, Redis-backed job queues, background jobs, delayed or repeatable jobs, worker processes, job scheduling, or async processing in a Node.js/TypeScript context. It is not for Redis infrastructure/cluster management itself, serverless queueing without Redis, complex saga/compensation workflow orchestration, event-sourcing architectures, or email-delivery specifics - each of those is explicitly delegated to a different named companion skill, and deployment/scaling concerns go to devops while monitoring/alerting/dashboards go to performance-hunter.

Input is a background-processing requirement (a job to queue, a schedule, a multi-step dependency chain) and its Redis connection details. Output is production-configured BullMQ queues, workers, and flows with explicit job options, backoff, concurrency limits (e.g. a worker set to a concurrency of 5), and graceful shutdown - flagged against ten validation checks for common misconfigurations.

Built on bullmq and ioredis, deployable against Upstash, Redis Cloud, ElastiCache, or Railway-hosted Redis, with monitoring via Bull Board, Arena, or BullMQ Pro, and delegating adjacent concerns to redis-specialist, upstash-qstash, temporal-craftsman, event-architect, and email-systems.

const connection = new IORedis(process.env.REDIS_URL, {
  maxRetriesPerRequest: null,  // Required for BullMQ
  enableReadyCheck: false,
});

Node.js/TypeScript developers building Redis-backed background job processing with BullMQ who need production-grade queue configuration, job flows, and shutdown handling, with clear delegation boundaries to adjacent infrastructure and workflow-orchestration concerns, working alongside adjacent skills like nextjs-app-router for the API layer that enqueues these jobs.