Queue backpressure on ESP outage

During an ESP outage, a queue worker without backpressure configuration becomes a thundering herd: all failed jobs retry immediately at full concurrency, exhausting the ESP's connection limit, burning through retry budget, and degrading IP reputation simultaneously. CWE-400 (uncontrolled resource consumption) and CWE-770 (allocation without limits) both apply. The damage compounds: by the time the ESP recovers, the IP may have accumulated enough connection-abuse signals to land in spam. Exponential backoff and a concurrency cap are not optional niceties — they are what prevents a 30-minute outage from becoming a 3-day reputation recovery.

Configure exponential backoff and a concurrency cap in your queue worker file (e.g., src/workers/email.worker.ts):

const worker = new Worker('email', processJob, {
  connection,
  concurrency: 10,
  limiter: { max: 100, duration: 60_000 } // 100 sends/minute
})

const defaultJobOptions: JobsOptions = {
  attempts: 5,
  backoff: { type: 'exponential', delay: 2000 }
}

Linear retry and full-concurrency defaults both fail this check. Quote the exact backoff type and delay values when reporting — "backoff configured" without specifics is not sufficient.