Art of Codeartofcode
Lesson 8 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.7 How does ordering work?

3 min read+10 XP

At the bank: One counter serves tokens in order. But with ten counters, token 48 might finish before token 47. Usually fine. But if your deposit and your withdrawal go to different counters, the withdrawal might be tried first and bounce.

In the system: A queue with many consumers doesn't preserve order: messages are handed out in order, but finish in whatever order the workers happen to finish. In the chapter's code, an order's "placed, paid, packed, shipped" events handed to 8 parallel workers come out scrambled.

Most of the time you only need order per key: all events for order 881 in order; order 881 and order 882 can interleave freely. The standard fix is partitioning by key:

events for order 881 go to the same partition and the same consumer, in order.

Figure: same key, same partition, one consumer at a time: order kept per key, parallel across keys.

  • Kafka: messages with the same key go to the same partition; a partition is read by one consumer in a group, in order.
  • SQS FIFO: messages with the same message group ID are delivered in order, one batch at a time.
  • RabbitMQ: a single consumer per queue, or consistent-hash routing to several queues.

In the chapter's code, partitioning by order ID keeps every order's steps in sequence.

Costs and alternatives:

  • A slow or stuck message blocks its partition (or group) until it's handled or dead-lettered.
  • Throughput per key is limited to one consumer.
  • Often you can avoid needing order: include a version or timestamp and ignore older updates (Chapter 19's versioned index updates), or make the consumer handle "paid before placed" by checking state.

Memory code: "Same key, same line, same clerk: order kept where it matters."