What is a message queue in simple words?

A message queue is a line of short notes. One part of a system adds them, and another takes each one later and does the work, so the user does not wait.

Does a message queue lose or repeat messages?

A good queue should not lose them, but it can repeat them. A message not marked done comes back after the visibility timeout. A standard queue can also send a rare extra copy with no crash, so a job may run twice.

Module 6 · Doing Work Later, Safely · Lesson 23 of 35

What is a message queue? Doing slow work later

12 minFree System design course · Beginner to intermediateLesson 6.1By Saket Bhatnagar

Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.

In short

What is a message queue? It is a line of short notes: one part of a system adds them, and another takes each one later and does the work.
It works like a cloud kitchen’s order rail: the order desk says “order accepted” at once, and the next free cook makes the dish.
A queue shortens the wait, not the work, and a job may sometimes run twice.

Soon

Video lesson · coming soon

What is a message queue? Saying Confirmed in 0.4 seconds

Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.

01 Six seconds, and a second tap
02 Chits on a cloud kitchen’s rail
03 Producer, queue, workers, side queue
04 A worker crashes, nothing is lost
05 When the line grows faster than workers
06 Next: who else wants every booking?

Kabir in Dehradun taps Book on seat A12. A spinner turns for six seconds. He thinks the app has frozen and taps again.

Meera Kulkarni’s support inbox fills with “app is stuck”, yet every booking worked. It is the slow checkout Zoya Mirza spotted: each booking waits for payment, ticket PDF, SMS and email.

“I will make the PDF code faster,” says Arjun Nair. Zoya uncaps a marker. “Even if it is twice as fast, the fan still waits for the PDF, the SMS and the email before seeing Confirmed. Which of those must happen before we say yes?”

Arjun sees it. Only the payment and the booking have to happen now. “But if we leave the rest for later,” he asks, “who remembers to do it? And what if whoever is doing it crashes?”

What is a message queue?

A message queue lets one part of a system leave a note for another part to handle later. Each note is a message, such as “make the ticket for BK-10442”.

At SeatJaldi, the booking service writes the notes.

Each note is taken by a worker, as in lesson 7, which finishes one job before taking the next. Keep one line in mind: say “done” for the fast part; put the slow part on the queue for workers.

Now: only what the fan must know before moving on.
Later: everything else goes on the queue.
Workers: each free worker takes the next message.
Side queue: a message that keeps failing waits for a person.

Producer, queue, workers and a side queue

Drag to explore

The booking service saves the booking, adds a message and answers the fan at once. Free workers take messages, and repeat failures move to a side queue that tells the team.

You have seen this when a shopping app says “Order placed” and the invoice email comes a minute later. The email waited on a queue.

Why use a message queue?

You use one so the user gets a fast “done” while slow parts finish in the background. A rush makes the rail longer, not Ganesh slower.

The queue runs in its own program.

Like a cook holding a chit, the broker hides a taken message instead of throwing it away. Then it waits for the worker to say “done”.

Try it yourselfOne booking, one crash, no lost ticketStep through Kabir’s booking. Watch when he gets his answer, and what the queue does when a worker dies.

What is a dead-letter queue?

A dead-letter queue is a side queue where messages go after failing too many times.

In Ganesh’s kitchen, a chit nobody can cook, “ghee roast, no ghee”, goes into the manager’s tray after five tries. And a tray helps only if someone looks.

What the queue does when things go wrong
What fails	What the queue does	Who sees it
A worker crashes holding a message	It reappears after the visibility timeout	Nobody, if the second try works
A message fails again and again	After 5 tries it moves to the dead-letter queue	An alert goes to the team
Messages arrive faster than workers finish	The line of waiting messages grows	An alert on how many wait and how old the oldest is

How do you run a queue safely?

A worker says “done” only after the whole job, usually by deleting the message, or it is handed out again. Even with no crash, a standard queue can now and then deliver the same message twice. So plan for repeats; a later lesson makes that safe. Messages can also finish out of turn: a retried one comes back late, and a queue on many machines only tries to keep order.

Before: 0.4 s booking and payment + 3 s PDF + 1.5 s SMS + 1.1 s email = 6 s (an assumed split).
After: 0.4 s. The other 5.6 s still happen, unseen.
Rush: say a league-match rush of 60 bookings arrives a second and workers finish 40. The line grows 20 a second: 12,000 after ten minutes (20 x 600).
Wait: the last of those waits 12,000 / 40 = 300 seconds, five minutes.

Little’s law counts the workers you need: busy workers = messages a second x seconds each. Each message keeps one busy about 5.6 s, so 40 a second keeps 224 busy, and 60 needs 336.

Run about 400 for spare room (336 x 1.2 = 403). They finish about 71 a second, 11 more than arrive, so the 12,000 waiting messages clear in about 18 minutes.

A growing line uses memory, and each new message waits longer. Alert on three things: how many messages wait, how old the oldest is, and a non-empty dead-letter queue. Ganesh’s manager watches the rail’s length.

Set the visibility timeout a little above the longest normal job. Say the slowest healthy job takes 10 s (an assumption); 30 s, the default in one well-known managed queue, leaves room. At 2 s, healthy jobs reappear mid-work and can run twice. At an hour, a crashed job waits an hour for its retry.

Without a dead-letter queue, a bad message keeps coming back until the queue drops it unseen, often after a few days. If the dead-letter queue fills with messages that look fine, the timeout is often too short.

json

{
  "type": "ticket.booked",
  "booking_id": "BK-10442",
  "match_id": 42,
  "seat_code": "A12"
}

What just happened? The message carries only the booking number, match and seat, not the PDF. The worker reads the rest from the database.

Stop a worker mid-job: the message must come back and get finished. Send one that always fails: it must reach the dead-letter queue and fire the alert.

Try it yourself

List the jobs
(a) Take the payment. (b) Sell the seat, only if it is still free. (c) Make the PDF. (d) Send the SMS. (e) Update the monthly sales chart.
Mark each one
Write “now” if the fan needs it before seeing Confirmed, or “later” for the queue, with one line on why.
Check your answer
(a) and (b) now: payment and sale are the promise, and the fan must know the seat is theirs. (c), (d) and (e) later: the PDF and SMS can come seconds after Confirmed, and nobody waits for the chart. Right if only (a) and (b) are now.

Back to Kabir. The next weekend he taps Book once and sees “Confirmed” in 0.4 s. A moment later the PDF, SMS and email arrive.

Behind the screen, worker-2 crashes mid-PDF. Thirty seconds later the message comes back, like a chit back on the rail, and worker-4 finishes it. Who remembers the work? The queue does.

Meera’s inbox goes quiet. Marketing, loyalty points and analytics all want to know about every booking. One queue, many listeners?

Check yourself

Arjun says, “With a queue, the whole booking job now finishes faster.” What is true?

Pick an answer to see why it is right or wrong.

Check yourself

A worker takes a message and crashes before saying “done”. What happens?

Pick an answer to see why it is right or wrong.

Check yourself

One message fails five times in a row. Where does it go, and who finds out?

Pick an answer to see why it is right or wrong.

Remember these three

Say “done” for the fast part; put the slow part on the queue for workers.
A worker must say “done”, or the message comes back after the visibility timeout, so a job can run twice.
Failing messages go to a dead-letter queue; alerts watch it, the waiting count and the oldest message’s age.

Questions people ask

What is a message queue in simple words?: A message queue is a line of short notes. One part of a system adds them, and another takes each one later and does the work, so the user does not wait.
What is a dead-letter queue?: A dead-letter queue is a side queue for messages that failed too many times. A person can look at them, fix the problem and put them on the queue again, so one bad message does not keep coming back unseen.
Does a message queue lose or repeat messages?: A good queue should not lose them, but it can repeat them. A message not marked done comes back after the visibility timeout. A standard queue can also send a rare extra copy with no crash, so a job may run twice.

What is a message queue?

Why use a message queue?

What is a dead-letter queue?

How do you run a queue safely?

Try it yourself

Check yourself

Questions people ask

Sources and further reading