bullmq-specialist

Use @nestjs/bullmq with InjectQueue in the API service to enqueue jobs via Queue.add, and a @Processor class extending WorkerHost in a separate worker app to process them. Keep the producer and consumer in different applications so workers scale independently.

Assign a deterministic jobId derived from the business key, such as provision-{tenantId}, so duplicate submissions are deduplicated. The processor logic must also tolerate retries, duplicates, and re-execution after restarts without repeating side effects.

Payloads should be minimal contracts containing ids, correlation keys, and only the context the worker needs. Avoid full entity snapshots, large objects, PII, secrets, or tokens; rehydrate data from secure sources inside the worker instead.

Use bounded retries with exponential backoff, for example attempts: 3 with a 1000ms base delay. Distinguish transient from permanent errors and route unrecoverable jobs to a DLQ or equivalent terminal handling instead of infinite requeue loops.

Tenant context must travel explicitly in the job payload or a secure context mechanism; it cannot be inferred from ephemeral producer state. Never hardcode schemas, tenants, or data paths inside the worker.

Avoid BullMQ to disguise coupling between modules, to store domain data persistently in Redis, or to hide real failures behind endless retries. Complex untested business logic should live in application services, not inside the processor.