Why some work does not belong in the request
Black Friday at your bookstore. Orders are pouring in. Each order needs a confirmation email, a PDF invoice, and an inventory sync. If you do all that inside the request handler, each order takes 5 to 10 seconds, your server chokes, and customers start getting timeouts. This is where every real backend reaches for a queue.
Fast response, slow work
The API saves the order and drops a job into the queue. A separate worker picks up the job and does the heavy lifting.
The response status to learn here is 202 Accepted. 201 Created means the resource exists and everything is done. 202 Accepted means we received it, we saved it, and the rest will happen later. Clients that understand the difference can poll the order status endpoint to check when processing finishes.
You can, and for low-volume workloads it even works. Redis wins because it is purpose-built for this. BullMQ on Redis handles concurrency, retries, dead-letter queues, delayed jobs, priorities, and back-pressure. Postgres can be made to do those things, but you end up rebuilding a queue library badly. Reach for the right tool.
Quiz: Quiz
Loading practice…