Queues and background jobs: don't make the user wait

Some jobs are slow: sending an email, resizing a video. Make the user wait for them and the whole app feels broken.

A queue is a waiting line of jobs the app does later, in the background, so the user gets an instant "got it" instead of a spinning wheel.

The idea: instead of doing a slow job while the user waits, the app drops it in a queue, and a background worker picks it up afterwards. The user's page returns immediately, and the work still gets done.

Wikipedia describes message queues as components that "use a queue for messaging, the passing of control or of content" between parts of a system. In plain terms: a to-do list one part writes and another works through.

Classic candidates are sending a welcome email, processing an upload, or generating a report. None of them should block the click that started it; the user shouldn't wait on work they don't need to watch.

Queues also save you under load. Heavy work done during the request is exactly what strains a CPU limit; when a spike of requests arrives, a queue lets the work wait its turn instead of overwhelming the app all at once.

Try it with the rules off. In the sandbox, set it to launch day and watch the queue build as users pour in, then drain as the workers catch up. A growing-then-shrinking backlog is healthy; a frozen page is not.

Next in when it breaks: What is scaling?.