Message queues
Some jobs are slow — sending an email, resizing a photo, charging a card. If your website does them right now while the user waits, the page hangs. The fix: scribble a 'to-do note,' drop it in a line called a queue, and instantly tell the user 'done!' A separate worker picks the note up later and does the slow part. The user never waited.
The restaurant ticket rail
Picture a busy restaurant. The waiter doesn't stand at your table cooking your food — they'd never get to anyone else. Instead they write your order on a ticket, clip it to a rail in the kitchen, and walk away to take the next table's order. The cooks grab tickets off the rail and cook them in order. That ticket rail is a message queue. The waiter is the producer (it makes the notes). The cooks are the consumers, or workers (they do the actual work). The note in the middle is the message. The whole point: the waiter never has to wait for the cooking, so the front of the restaurant stays fast no matter how slow the kitchen is.
Why bother? Three things it buys you
First, decoupling. The website and the slow worker no longer have to be busy at the same moment. The website just drops the note and is free again. If the worker is slow today, the website doesn't even notice — the notes just wait on the rail. Second, buffering bursts. Imagine 1,000 orders arrive in one second. A worker can only cook so fast — but that's fine, the queue simply holds the pile of 1,000 notes and the worker chews through them steadily. Without the queue, that burst would have crushed the slow part and crashed it. Third, resilience. The note lives safely in the queue until a worker says 'I finished this one.' So if a worker trips over a cable and dies mid-job, the note is still sitting in the queue — another worker just picks it up. Nothing is lost.
The catch: 'later' really means later
A queue makes work asynchronous — a fancy word that just means 'not right now, a bit later.' That's a trade. The user gets a fast 'we're on it!' instead of waiting, but the actual result (the email lands, the photo finishes resizing) happens a few seconds — sometimes minutes — afterward. So you use a queue for work the user is happy to wait on in the background (send a receipt, generate a report). You do NOT use it for things the user needs answered this instant, like 'what's my account balance?' — that one you just do right now and hand straight back.
It's a tradeoff
| Option | 👍 Pro | 👎 Con |
|---|---|---|
| Do it now (synchronous) | Simple, and the user gets the real result immediately — perfect when the work is fast or the answer is needed right away. | If the work is slow, the user waits. A burst of requests can pile up and crash the slow part. |
| Queue it (asynchronous) | The site stays fast, soaks up bursts, and survives a worker dying — the note waits safely until someone finishes it. | The result happens later, not instantly, and you've added a moving part (the queue + workers) to run. |
Questions you might have
▸Wait — if the work happens 'later,' how does the user know it worked?
The website tells the user 'we got your request!' the moment the note hits the queue. Then, when the worker actually finishes, it lets the user know separately — an email arrives, a little 'done' notification pops up, or the page updates. The user just doesn't have to sit and stare at a spinner while the slow part runs.
▸What if a worker grabs a note and then crashes before finishing?
That's the whole reason the queue is great. The note isn't deleted when a worker grabs it — only when the worker reports 'finished.' So if the worker dies mid-job, the note is still in the queue and another worker picks it up. The work just gets retried, nothing is lost.
▸Can I just have lots of workers if the pile gets too big?
Yes! That's a big perk. If the queue keeps growing because work arrives faster than one worker can handle, you simply add more workers all pulling from the same rail. They share the pile and clear it faster. The queue makes adding helpers easy.
▸Isn't this just a normal queue, like the data structure?
Same idea — first note in is the first note out (FIFO) — but here the queue lives between two different programs that may run on different computers, and it remembers the notes safely even if a program crashes. It's a queue with a memory and a delivery guarantee, not just a list in one program's memory.
Best read after: Stateless vs. stateful