What failure can occur if a consumer commits before processing a record?

If the offset is committed first, the group has declared 'this record is done' before it actually is. If the consumer crashes, is killed during a deploy, hits an exception, or loses its partitions in a rebalance after the commit but before the processing completes, the next owner resumes from the committed offset, which is already past that record. The record is never processed again. Nothing in Kafka flags this: lag looks healthy, the offsets look perfect, and the data is simply missing downstream. That is at-most-once semantics: each record is processed zero or one times, never twice.

This often happens unintentionally. Auto-commit combined with handing records to another thread commits offsets for records that are still queued. A catch block that logs an exception and continues, while the loop commits regardless, converts a processing failure into a silent skip. Committing at the top of the loop 'to be safe against duplicates' does the same. At-most-once is sometimes a legitimate choice, for example for metrics or sampling where a lost event is cheaper than a duplicate, but it should be a deliberate decision. For business events the standard fix is to process first, commit after, accept at-least-once and make handlers idempotent. For records that can never be processed, the answer is not to skip them silently but to publish them to a dead-letter topic and then commit, so the skip is recorded and recoverable.