Message DeliveryAcknowledgementsRetriesIdempotencyjunior level

Message delivery semantics under failure

the question

What is the difference between at-most-once, at-least-once, and exactly-once message delivery? How do acknowledgements and retries produce those guarantees?

what they're testing: The interviewer is probing whether you can reason about failure windows and choose a delivery guarantee that keeps application state correct.

a strong answer

The terms describe what can happen to an accepted message within a system's stated failure model:

At-most-once: zero or one delivery. Uncertain work is not retried, so a message may be lost but is not redelivered.
At-least-once: one or more deliveries. Unacknowledged work is retried, so the same message may reach the consumer again.
Exactly-once: the message's result appears once within a defined scope. The system may still make more than one physical attempt.

Acknowledgement timing creates the trade-off. If a consumer acknowledges before its work is durable, it can crash after the acknowledgement and lose that work. If it makes the change first, it can crash before acknowledging. The broker then redelivers a message whose effect may already exist. At-least-once consumers should therefore make effects idempotent, using an upsert or a unique message ID recorded with the state change.

Exactly-once needs a clear boundary. A broker may deduplicate publishes or atomically commit an input offset with output records. That guarantee does not automatically include a separate database update or an email. For those effects, use a shared transaction where possible or design the operation to tolerate retries.

Where people slip

the tempting wrong answer, and what's actually true

At-most-once means every message is delivered once, with duplicates filtered out.
At-most-once allows zero deliveries, so avoiding redelivery comes with a risk of message loss.
At-least-once guarantees that the consumer processes each message only once.
At-least-once permits redelivery, so the consumer may receive and process the same message more than once.
Acknowledging after processing gives exactly-once behavior.
Acknowledging afterward is not atomic with the side effect. A crash between them can make the broker redeliver work that already succeeded.
A broker's exactly-once feature guarantees every external side effect happens once.
Exactly-once guarantees apply only within their documented boundary, and external effects need their own atomicity or idempotency.

If they push further

How would you make an at-least-once consumer safe?

Make the operation naturally idempotent or record a unique message ID in the same transaction as the state change. A redelivery can then repeat safely or be skipped.

Why can a message be redelivered after the handler succeeded?

The handler may finish and then crash or lose its connection before the broker records the acknowledgement. From the broker's view, retrying is safer than dropping the message.

Does exactly-once delivery mean exactly-once processing?

Not necessarily. State the guarantee's boundary and check whether the consumer's side effect and message progress are committed atomically inside it.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.