At-Most-Once vs At-Least-Once

Kafka · lesson 9 of 34 · 3 min read

Pick a delivery guarantee on purpose, and see that the choice is really about when you commit.

Open this lesson in the learning hub

Key points

  • At-most-once: commit the offset before processing. Crash and the record is skipped forever. Fast and lossy.
  • At-least-once: process, then commit. Crash and you reprocess the batch. This is the sane default.
  • At-least-once means duplicates will happen. Your handler must be idempotent — upsert by id, never blind insert.
  • Exactly-once in Kafka means read-process-write inside one Kafka transaction. It is not magic across your whole system.
  • A call to an external database or third-party API sits outside that transaction. Deduplicate there with a unique constraint on the event id.
  • Practical rule: at-least-once delivery plus idempotent processing gives exactly-once effects, which is what anyone actually wanted.

At-least-once with idempotent handlers beats chasing exactly-once everywhere.

Replication and the ISR Idempotent and Transactional Producers

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Kafka course, and every lesson in it is listed on the Kafka contents page.