Worker
A separate always-on process that pulls jobs off the queue and runs them, so your web server can stay busy answering requests.
See it
What it is
A worker is a long-running process whose whole job is to pull tasks off a queue and run them. It shares your codebase and your database but answers no HTTP requests: it loops, claims a job, does the work, acknowledges it, repeats. In practice it is a separate process type in your deploy config (the 'worker' line in a Procfile, a second service in docker-compose, its own container in Kubernetes) started with a different command than the web server.
Splitting workers from web servers is what lets you scale the two independently: a backlog of 20,000 image conversions means run more workers, not more web dynos. Concurrency has two dials, processes and per-process concurrency, and the right setting depends on the work. IO-bound jobs (waiting on APIs) tolerate high concurrency; CPU-bound jobs (image and video processing) want roughly one per core.
Traps worth knowing. Workers get killed mid-job during every deploy, so handle SIGTERM: stop claiming new jobs, finish the current one, then exit, and make sure the queue redelivers anything that did not finish. Workers also hold database connections, so count them in your pool math or they will quietly starve the web tier. And a worker with no logs, no metrics, and no alert on queue depth is a machine failing in silence: nobody notices a broken worker until a customer asks where their receipt went.
Ask AI for it
Add a background worker process to this app. Create a separate entrypoint that starts a queue consumer (BullMQ Worker or equivalent), register the job handlers, and add it as its own process type in the Procfile, docker-compose service, and deploy config so it scales independently of the web server. Set concurrency based on the workload (high for IO-bound jobs, about one per core for CPU-bound). Handle SIGTERM for graceful shutdown: stop accepting new jobs, let the in-flight job finish within a timeout, then exit. Emit structured logs per job and expose queue depth plus job duration as metrics with an alert on a growing backlog.