auto.offset.reset applies when a consumer group has no committed offset for a partition (new group, or offsets expired).
latest (common default)
Start at the end of the log: only new messages after the consumer starts.
Use when you care about live events and do not want a huge backlog replay on first subscribe.
earliest
Start at the beginning of the retained log: replay history.
Use for new analytics jobs, backfills, or when missing old events is unacceptable.
partition log: [0][1][2][3][4][5] (5 = newest) earliest → start at 0 (replay all retained) latest → start after 5 (only future)
Important nuance
This setting does not override an existing committed offset. If the group already committed offset 100, the consumer continues from there regardless of earliest/latest.
Offsets can also be expired by retention on __consumer_offsets or by manual reset tools. Then auto.offset.reset kicks in again.
Interview scenario
"We deployed a new fraud service with a fresh group id. With latest we missed yesterday's events; with earliest we replayed 7 days of traffic and overloaded the DB." Both outcomes are about choosing reset + capacity carefully.
Interview tip: "earliest = replay retained history; latest = only new. Only used when no committed offset exists."