Run workers
with the right limits.

Image work spends memory outside the JavaScript heap. Run workers separately from the upload API and measure representative source images before raising concurrency.

Retries and dead letters

The BullMQ adapter defaults to three attempts with exponential backoff starting at five seconds. When attempts are exhausted, it marks the asset failed and copies the job to a bounded dead-letter queue. A retained completed or failed job can be replaced for an intentional rerun.

Stalled attempts

A hard process kill cannot emit a queue failure event. If the repository implements reapStalled, the worker periodically asks it to fail old processing attempts. The defaults are a five-minute sweep interval and a 30-minute stale threshold; both are configurable.

Memory and concurrency

The image engine defaults to one Sharp/libvips thread per operation and the BullMQ worker defaults to two concurrent jobs. Sharp uses native memory outside the V8 heap. Put the worker in a dedicated container with an explicit memory limit, and test worst-case inputs before increasing either setting.

Redis isolation

Use a dedicated Redis instance or logical database for media queues so queue cleanup and memory accounting do not affect unrelated application jobs.

Deploy order

Deploy consumers that understand a new job schema before producers start writing it. The current job payload contains an asset ID and an internal enqueue token; the worker retrieves mutable details from the repository.