ulearn/systems

topics / async-messaging

RabbitMQ vs Kafka

Smart broker vs. dumb log — not a benchmark, a difference in what each one actually does at runtime. Watch the same published event get pushed to a worker and deleted on ack on one side, while it sits in a log getting pulled by independent consumer groups on the other. Then use Match to score a workload's traits, or Study for the full scenario-by-scenario reasoning.

Every term this topic uses, defined once. Anywhere you see a word with a dotted underline — on Simulate, Match or Study — hovering (or tapping, on touch) shows the same definition inline; this page is just the full list in one place.

RabbitMQ vocabulary

Exchange

Where a RabbitMQ producer actually publishes to — never straight to a queue. Its type (direct, topic, fanout, headers) decides how it matches messages to the queues bound to it. This is where RabbitMQ's routing intelligence lives.

Binding

The link between an exchange and a queue, optionally filtered by a routing-key pattern (e.g. orders.eu.*). A message can fan out to several queues if several bindings match it.

Queue

A durable, ordered backlog of messages in RabbitMQ. A message sits here until a consumer pulls and acks it, at which point it's deleted — a classic or quorum queue doesn't keep it around afterward.

Ack (acknowledgment)

A consumer's explicit signal to RabbitMQ that it's actually finished processing a message — not just received it. Once every queue a message was routed to has acked it, the broker deletes it for good.

Prefetch

A cap on how many unacked messages one RabbitMQ consumer can hold at once, so one slow worker can't hoard the whole backlog while other workers sit idle.

Competing consumers

A pool of workers pulling discrete jobs off one shared backlog, where each job is handled by exactly one worker. RabbitMQ's queue model — per-message ack, prefetch, redelivery on crash — is purpose-built for this pattern.

Kafka vocabulary

Topic

A named stream in Kafka, split into partitions for horizontal scale. Producers publish to a topic; consumer groups read from it independently, each at their own pace.

Partition

One ordered, append-only slice of a Kafka topic, replicated across brokers for durability. Order is only guaranteed within a single partition, never across a whole topic.

Partition key

The value (often a user id or order id) Kafka hashes to pick which partition a message lands on. Same key, same partition, every time — which is what makes 'ordered per key' free instead of something you build.

Log

Kafka's core structure — an append-only sequence of messages, written once and never edited. Consumers read it by position rather than by removing entries, which is exactly why the same message can be read by many independent readers.

Offset

The position of the next message a Kafka consumer group will read in a partition — its bookmark in the log. Replay is just resetting this number backward; it's tracked per group, independently of every other group reading the same topic.

Consumer group

A set of Kafka consumers that split a topic's partitions between them — each partition goes to exactly one consumer in the group at a time. Two different groups reading the same topic never affect each other's offset.

Retention

How long Kafka keeps a message in the log — a time window, a size cap, or forever for a compacted topic — regardless of whether anyone's read it yet.

Eviction

A Kafka log entry aging out once it exceeds the topic's retention window — deleted whether or not any consumer group ever read it. A group sitting on an offset that falls outside the window gets snapped forward to the oldest entry still available.

Replay

Reprocessing messages a consumer already read once, by resetting a Kafka consumer group's offset backward. There's no equivalent in a default RabbitMQ queue — once a message is acked, it's gone for good.

Poll rate

How often, per second, a Kafka consumer group pulls the next message off its partition. Unlike RabbitMQ, nothing is pushed to it — a slow poll rate just means the group falls further behind the live edge, not that messages back up waiting for it.

Shared

Fan-out

Delivering the same message to every interested consumer, not just one. In RabbitMQ this is a fanout exchange bound to several queues (one full copy of the stream each); in Kafka it's several independent consumer groups reading the same log.