Art of Codeartofcode
Lesson 3 of 18

22. Message Queues

1
The picture to keep in your head
2
22.1 What are producers and consumers?
3
22.2 Why go async?
4
22.3 What are the delivery guarantees?
5
22.4 How do acks and visibility timeouts work?
6
22.5 What are retries and dead-letter queues?
7
22.6 What is an idempotent consumer?
8
22.7 How does ordering work?
9
22.8 What is backpressure?
10
22.9 How do you scale consumers?
11
22.10 Log (Kafka) vs queue (RabbitMQ, SQS): what's the difference?
12
22.11 How do delayed and scheduled jobs work?
13
Memory card and where the analogy breaks
14
Practice: five levels
15
Interview questions
16
Solutions
17
Sources
18
Code lab
22. Message Queues

22.2 Why go async?

3 min read+10 XP

At the bank: Without tokens, everyone stands in one line at one counter. One slow customer holds up everyone behind them. With tokens, you're free to sit, the bank can add counters, and a slow case doesn't stop the room.

In the system: Doing everything synchronously inside the "place order" request means the customer waits for every step, and any step failing fails the whole order:

sync: save, SMS, slip and points in a row, about 1.8 s; async: save and enqueue, about 60 ms.

Figure: the customer only waits for what must happen now; the rest happens in the background.

What a queue buys you:

  • Faster responses. Save the order, enqueue the follow-up jobs, reply. With the illustrative timings above, about 60 ms instead of 1.8 seconds.
  • Failure isolation. If the SMS gateway is down, orders still go through; SMS messages wait in the queue and go out when it recovers.
  • Smoothing spikes. At a Big Sale, orders arrive faster than the SMS gateway allows. The queue absorbs the burst and workers drain it at a steady pace (22.8).
  • Independent scaling. Add more SMS workers without touching checkout.

What it costs:

  • Eventual, not immediate. The SMS arrives seconds later, not before the "order placed" screen. Show "we'll text you shortly", not "SMS sent".
  • More moving parts: the broker to run and monitor, retries, duplicates (22.3) and ordering (22.7) to think about.
  • Harder debugging: one request now spans several processes. Pass a correlation ID in each message (Chapter 30).

Rule of thumb: do synchronously what the user needs to see now (save the order, take the payment); queue what can happen a moment later (emails, SMS, thumbnails, analytics, search indexing).

Memory code: "Do now what they must see; queue what can wait a moment."