What this prompt does
This prompt has the model act as a senior backend engineer and design a production-grade background job system on BullMQ and Redis, returning working code rather than pseudocode. It focuses on the reliability details that separate a queue that survives real traffic from one that loses jobs: exponential backoff, capped retries, a dead-letter queue for exhausted jobs, idempotent handlers, and graceful shutdown. The result is meant to be right the first time, not bolted on after an incident exposes the gaps.
The [runtime] variable sets the language and module system the code is written in, so the producer and worker match your codebase. [queues] lists the specific queues to create, which shapes the per-queue concurrency and rate-limit config. [redis_host] tells the model where Redis lives — managed, TLS, or local — affecting connection setup and reuse. [throughput] sizes the design: expected steady volume plus bursts informs concurrency and rate limiting so a spike doesn't overwhelm Redis or downstream services, and it shapes how aggressively the workers pull jobs.
When to use it
- A SaaS API is slowing down because emails, exports, or webhook fan-out run inside request handlers.
- You need retries with backoff and a dead-letter queue done right the first time, not after an incident.
- Adding scheduled or repeatable cron-style jobs and delayed jobs to an existing service.
- Standing up a BullBoard dashboard so operators can see stalled and failed jobs.
- You want a worker you can unit-test without spinning up a live Redis instance.
- Sizing concurrency and rate limits for a known burst pattern instead of guessing.
Example output
You get a producer module, a worker module, the queue config, and a short gotchas list covering stalled jobs, clock skew, and memory growth. The reliability layer includes exponential backoff, max attempts, and a dead-letter queue for exhausted jobs, with idempotent handlers so a retried job doesn't double-charge or double-send. Operations cover a BullBoard dashboard, SIGTERM graceful shutdown, and per-attempt structured logging, plus scheduling for cron, repeatable, and delayed jobs. It's a runnable scaffold sized to your [throughput], not a generic snippet.
Pro tips
- Be precise with
[throughput]— the steady rate and the burst ceiling drive concurrency and rate-limit choices, and a vague number gives you a vague config. - List real queue names in
[queues]; each one gets its own concurrency and rate limit, so lumping them together hides the tuning you actually need. - Set
[redis_host]accurately, including TLS for managed Redis, so connection reuse and auth are correct from the start. - Make handlers idempotent before you scale up — retries and at-least-once delivery mean a job can run twice.
- Match
[runtime]to your project so the producer and worker share the same module system and syntax as the rest of the code. - Paste your current in-handler job code under the prompt for a tighter, migration-style answer instead of a from-scratch design.
