At-Most-Once: Fire and Forget

At-most-once is the least discussed semantic but it appears in interviews as a trap. The interviewer describes a use case (monitoring metrics, debug logs) and waits to see if you over-engineer it with exactly-once. The strong candidate says 'this is at-most-once territory; losing a few metrics samples is acceptable and the simplicity is worth it.'

How It Works

Commit the offset BEFORE processing. If the consumer crashes after committing but before finishing, the message is lost. No retry, no reprocess. The message is gone.

When At-Most-Once Is Correct

The Interview Trap

The interviewer says: 'We need to send CPU metrics from 10,000 servers to a monitoring dashboard every 5 seconds.' The trap is over-engineering this with exactly-once semantics. The strong answer: 'At-most-once. If we lose one sample out of 12 per minute, the dashboard still shows an accurate trend. The simplicity and throughput gains outweigh the negligible data loss.'

Knowing when NOT to use a complex solution is a stronger signal than knowing how to implement one. 'I would use at-most-once here because the business cost of a lost metric sample is zero, and the engineering cost of exactly-once adds latency and complexity with no business value.'

About this lesson

This section is part of the Delivery Semantics: Advanced lesson on DataDriven, the home of data engineering. Lessons cover SQL, Python, Spark, data modeling and pipeline architecture, and each section pairs its explanation with worked examples and practice you run as you go.