Module 15 / Messaging and event logs

Module 15 · lesson 7 of 8 · Read 8 min

Kafka, SQS, RabbitMQ or Pulsar?

Queues and logs side by side, and what their ordering and exactly-once claims cover.

This module has used Kafka for order events, and Module 7 used a plain queue for receipts. In a design discussion someone will ask "why Kafka and not SQS?", or suggest RabbitMQ or Pulsar. The four overlap enough to be confusing and differ enough that the wrong choice hurts.

This lesson puts them side by side, including the parts the marketing pages blur: what "in order" and "exactly once" actually mean in each.

Two families

Underneath the product names there are two designs.

  • A queue hands each message to one consumer and deletes it once that consumer acknowledges it. Nothing is kept for later. SQS and RabbitMQ's queues work this way.
  • A log keeps every message for a retention period, and each reader tracks its own position. Many readers can read the same messages, and any of them can rewind. Kafka works this way, and so do RabbitMQ's streams.

Pulsar does both: it stores a log, and each subscription chooses whether to read it like a log or share it out like a queue.

Pick the family first. If several services need the same events, or you'll ever need to replay them, you want a log. If each message is one job for one worker, a queue is simpler.