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

> Sign in to view the full content of this lesson.

## 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.