At-most-once and at-least-once, worked through both brokers

Learning objectives

By the end of this lesson you can:

Define at-most-once and at-least-once by where the progress confirmation sits relative to your processing code.
Trace Kafka's offset commit window and point at the exact instruction where a record is lost or duplicated.
Trace RabbitMQ's basic.ack window and point at the same two instructions.
Explain why enable.auto.commit and autoAck=true quietly push you toward at-most-once.
Read a production incident and say which window it fell into.

Quick review

From lesson 1.1: Kafka keeps an append-only log and the consumer owns its position, a number called the offset, stored in the __consumer_offsets topic. RabbitMQ keeps messages in a broker-managed queue and deletes a message once the consumer acknowledges it. Hold on to that split, because who records progress is what makes the two delivery windows look different even though the underlying question is identical.

Theory

One question decides everything

Both brokers see the same three events: a message is produced, a consumer receives it, and progress is recorded. The semantics come entirely from the ordering of the last two.

At-most-once: record progress before processing.
At-least-once: record progress after processing.

In Kafka, "record progress" means committing an offset. In RabbitMQ, it means sending basic.ack. Note that basic.ack here is the consume-side acknowledgement, not a publisher confirm.

Cloze check: at-most-once confirms {{c1::}} processing, at-least-once confirms {{c2::}} processing.

At-most-once, both brokers

Kafka: commit the offset, then process. RabbitMQ: autoAck=true, where the broker removes the message as soon as it writes it to the socket.