22. Message Queues
22.10 Log (Kafka) vs queue (RabbitMQ, SQS): what's the difference?
At the bank: The token board throws away each slip once it's served: one clerk, one job, gone. Now picture instead a ledger: every transaction is written down in order and kept. The cashier reads it, the auditor reads it, the fraud team reads it, each at their own pace, each with their own bookmark. And the auditor can go back to page one.
In the system:
Figure: a queue hands out jobs; a log keeps a history that many readers can replay.
| Queue (RabbitMQ, SQS) | Log (Kafka, Kinesis, Pulsar) | |
|---|---|---|
| After processing | Message deleted | Message kept for a retention period (Kafka defaults to 7 days) |
| Who gets a message | One consumer | Every consumer group gets every message |
| Position tracking | Broker tracks per message (acks) | Consumer tracks an offset per partition |
| Replay | No | Yes: move the offset back |
| Ordering | Usually none (FIFO options exist) | Per partition |
| Per-message features | Acks, delays, priorities, DLQs built in | Fewer; you build retries and DLQs as topics |
| Sweet spot | Jobs and tasks: send this email, resize this image | Event streams: many services reacting to "order placed", analytics, CDC |
In the chapter's code, an SMS group and an analytics group both read all five "order placed" events from the same log; the analytics group then rewinds to offset 0 and reads them again.
How teams combine them: Kafka as the backbone of business events ("order placed", "payment captured"), each service consuming what it needs; queues for task work inside a service ("send these 10,000 emails").
Memory code: "A queue hands out slips and bins them; a log keeps the ledger for every reader."