consumer
offset
system design
kafka
What determines Kafka consumer offset?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
The Kafka consumer offset is a numerical identifier that represents the position of a consumer in a Kafka partition. It determines which message the consumer will read next from a specific partition.
Factors That Determine the Kafka Consumer Offset
- Consumer Group
- Offsets are managed per consumer group. Each group has its own unique offset for each partition.
- Multiple consumer groups consuming from the same topic will maintain independent offsets.
- Partition
- Each partition within a topic maintains its own offset.
- Consumers track offsets independently for each partition they consume from.
- Offset Storage Kafka stores offsets for consumer groups in one of the following ways:
- Kafka Broker (default):
- The consumer offsets are stored in the internal topic
__consumer_offsets.
- Manual Storage:
- Consumers can store offsets externally (e.g., in a database) for more control, but this is uncommon.
- Offset Management Strategy
- Consumers can manage offsets automatically or manually.
- Automatic Offset Commit (default):
- Kafka automatically commits offsets at regular intervals (controlled by the
auto.commit.interval.mssetting). - Configured with
enable.auto.commit = true.
- Manual Offset Commit:
- The consumer application commits offsets explicitly using the
commitSync()orcommitAsync()methods for better control. - Configured with
enable.auto.commit = false.
- Consumer Start Position
- When a consumer starts consuming for the first time, it needs to know where to begin. This is controlled by:
auto.offset.resetsetting:earliest: Start from the beginning of the partition.latest: Start from the most recent message.none: Fail if no previous offset is found.
- If a consumer restarts and its previous offsets are available (e.g., in
__consumer_offsets), it will resume from those offsets.
- Rebalancing
- During a consumer group rebalance (e.g., when consumers join or leave the group), partitions are reassigned, and offsets are re-evaluated.
- Consumers will resume from their last committed offset for their new assignments.
- Offset Reset
- If the consumer cannot find its last committed offset (e.g., due to retention expiration in
__consumer_offsets), it will fall back to the behavior defined byauto.offset.reset.
- Time-Based Offset Search
- Consumers can seek offsets based on a specific timestamp using the
seek()API. Kafka finds the offset closest to the provided timestamp.
Key Configuration Parameters Affecting Offsets
| Parameter | Description |
enable.auto.commit | If true, offsets are automatically committed. Default is true. |
auto.commit.interval.ms | Interval for automatic offset commits. Default is 5000ms. |
auto.offset.reset | Determines the start position if no offset is found (earliest, latest, none). |
group.id | Consumer group ID, which determines the set of offsets for this consumer. |
session.timeout.ms | Determines the timeout for detecting consumer group member failures. |
max.poll.interval.ms | Maximum interval between polls to avoid consumer being marked as unresponsive. |
partition.assignment.strategy | Determines how partitions are assigned during rebalancing (range, roundrobin, etc.). |
Offset Lifecycle
- Start: A consumer checks its last committed offset from Kafka.
- Consume: Messages are read sequentially from the current offset.
- Commit: The consumer commits its current position to Kafka:
- Automatic: Commit happens periodically.
- Manual: Commit happens explicitly via API calls.
- Rebalance: If a rebalance occurs, offsets are redistributed according to the consumer group's state.
Summary
Kafka consumer offsets are influenced by:
- The consumer group, partition, and offset storage location.
- The configuration for offset management, such as
enable.auto.commitandauto.offset.reset. - Events like rebalancing and explicit offset commits.
Proper management of consumer offsets is essential for ensuring reliable message processing and maintaining the desired consumption semantics.

