What is a queue?
A queue is a waiting line for work. Instead of doing a slow job right now while the user watches a spinner, you write a small note describing the job — "send a receipt for order #4127" — drop it in the line, and answer the user immediately. Separate machines called workers pull notes off the line and do the slow jobs at their own pace.
You already know this move from real life. The barista does not stand idle until your latte is finished before greeting the next customer — they take your order (fast), stick the cup in the line (the queue), and a second barista (the worker) makes drinks one by one. The register never blocks on the espresso machine.
The trick works on one condition: the user does not need the result of the slow work to continue. You can leave the coffee shop counter without your latte in hand; you cannot leave without knowing your card was accepted.
- producer
- — the code that drops a job onto the queue (your app server)
- worker (consumer)
- — a process that pulls jobs off the queue and does them
- backlog
- — jobs waiting in the queue that no worker has picked up yet
Words to know
Checkout takes 4.5 seconds
SliceNow's menu reads are fixed — the cache from last lesson absorbed them. But now customers are abandoning CHECKOUT. Placing an order does five things in a row while the customer stares at a spinner: save the order (300ms), charge the card (700ms), email a receipt (2 seconds — the email provider is slow), render a PDF invoice (1.5 seconds), and update loyalty points (100ms).
Look at that list again with one question: which of these does the customer actually need to finish before seeing "Order placed!"? The order must be saved and the card must be charged — those are the answer to their question. The receipt email, the PDF, the loyalty points? Nobody refreshes the page waiting for an email.
So the app does the two must-dos, drops three job notes onto a queue — "email #4127", "pdf #4127", "points #4127" — and answers in 1 second instead of 4.6. Workers grind through the notes seconds later. The customer never knew.
Checkout before
4.6 sec
Checkout after
~1 sec
Email provider
2 sec (unchanged!)
Quick check
A customer places an order. Which piece of work CANNOT go onto the queue?
One order, traced through the queue
Follow order #4127 step by step. The app server saves the order row (300ms) and charges the card (700ms). Then it enqueues three small notes — each just a job name and the order id, a few hundred bytes — which takes about 5ms total. It replies "Order placed!" at the 1-second mark.
Meanwhile a worker machine sits in a loop: pull the oldest note, do the job, delete the note, repeat. It pulls "email #4127", spends the full 2 seconds talking to the email provider, deletes the note. Another worker pulls "pdf #4127" at the same time — two workers, two jobs, in parallel.
Notice what the queue bought you: the email provider is exactly as slow as before. Nothing got faster. The slowness just moved to a place where nobody is watching — and that is the whole point.
Now vs later — how to split any request
The question is always: does the user need this result to continue?
| Work | User needs the result? | Where it runs |
|---|---|---|
| Save the order | Yes — it IS the answer | Now, while they wait |
| Charge the card | Yes — failure changes everything | Now, while they wait |
| Receipt email | No — arrives whenever | Queue → worker |
| PDF invoice | No — downloaded later | Queue → worker |
| Resize uploaded photos | No — thumbnails can lag | Queue → worker |
| Notify the kitchen | No — but soon matters | Queue → worker (fast lane) |
Tip — The hidden superpower: absorbing spikes
Friday 7pm brings 400 orders a minute but your workers only manage 200 emails a minute. Nothing breaks — the backlog simply grows, checkout stays instant, and workers catch up at 9pm. The queue turned a traffic spike into a longer to-do list instead of an outage. (Watch the backlog length on a dashboard: if it grows all day and never shrinks, you need more workers.)
Quick check
Your workers process 200 jobs/minute but Friday rush enqueues 400 jobs/minute for one hour. What do customers experience during that hour?
Match them up
Match each term to its plain meaning.
0/5 matched — tap a term on the left.
Build it yourself
Rebuild SliceNow checkout so the customer only waits for what matters. The order must be saved in the database NOW; the receipt work goes through a queue to workers. One palette piece cures a read-shaped pain we already fixed — leave it off.
Common trap — When NOT to queue
Never queue work whose RESULT the user is waiting on: payment authorization, a login check, "is this username taken?". Queueing those does not hide the wait — it replaces the answer with a shrug. And remember jobs can fail out there: workers should retry, and a job that keeps failing goes to a "dead letter" pile a human can inspect, not into silent oblivion.
Apply it in an interview
The URL-shortener problem hides a queue-shaped decision: click analytics on the redirect path. Should a redirect wait for the click to be recorded? Design it and defend your answer.