auto.offset.reset configuration controls this behavior and is critical for understanding data processing guarantees.
What you’ll learn:
- The three auto offset reset options and when each is triggered
- How to choose the right setting for your use case
- Best practices for production and development environments
- How to handle offset reset scenarios programmatically
Auto offset reset options
When a Kafka consumer starts and there are no committed offsets for its consumer group, or when the committed offset is no longer valid (e.g., because the data has been deleted), the consumer needs to decide where to start reading from. This behavior is controlled by theauto.offset.reset configuration.
earliest
- Consumer will start reading from the beginning of the partition
- Reads all available messages from the earliest available offset
- Useful for reprocessing all historical data
- Use case: Data migration, audit requirements, complete reprocessing
latest (default)
- Consumer will start reading from the end of the partition
- Only processes new messages produced after the consumer starts
- Use case: Real-time processing where historical data is not needed
none
- Consumer throws an exception if no previous offset is found
- Forces explicit offset management
- Use case: Strict control over consumer behavior, prevents accidental data loss or reprocessing
Decision guide
When auto offset reset is triggered
Theauto.offset.reset behavior is triggered in these scenarios:
| Scenario | Description | Example |
|---|---|---|
| New consumer group | First time a consumer group subscribes to a topic | Deploying a new application |
| Invalid offset | Committed offset no longer exists (data deleted due to retention) | Consumer offline longer than retention period |
| Offset out of range | Committed offset is beyond the current log boundaries | Log truncation or corruption |
Common scenarios
Scenario 1: New consumer group
Scenario 2: Data retention cleanup
Best practices
For production systems
For development/testing
For critical data processing
Error handling example
Offset management strategies
Automatic offset management
- Use
enable.auto.commit=true - Set appropriate
auto.commit.interval.ms - Choose suitable
auto.offset.resetpolicy
Manual offset management
- Use
enable.auto.commit=false - Call
commitSync()orcommitAsync()after processing - Handle offset reset scenarios explicitly
External offset storage
- Store offsets in external systems (database, file system)
- Use
seek()methods to position consumer - Implement custom offset management logic
Configuration recommendations
| Use case | auto.offset.reset | enable.auto.commit | Notes |
|---|---|---|---|
| High-throughput | latest | true | Accept potential data loss for speed |
| Critical data | none | false | Manual control, handle exceptions |
| Replay scenarios | earliest | false | Process all historical data |
| Development | earliest | true | Easy testing with full data |
See it in practice with ConduktorConduktor Console lets you monitor consumer group offsets and lag in real-time. Identify when offset resets occur and track consumer position across partitions to validate your offset management strategy.
Next steps
- Understand delivery semantics for exactly-once processing
- Configure consumer settings for optimal performance
- Manage consumer groups with CLI for operational tasks