Offset management in Kafka - Commands & Configuration

Introduction

When you read messages from Kafka, you need to remember where you left off. Offset management helps track this position so you don't read the same message twice or miss any messages.

When you want to process messages from a Kafka topic without losing or repeating data.

When your consumer application crashes and you want to resume reading from the last processed message.

When multiple consumers share the same group and you want to balance message processing.

When you want to manually control which messages your consumer reads next.

When you want to reset or rewind your consumer to reprocess messages.

Commands

This command shows the current offset positions for each partition in the consumer group 'my-group'. It helps you see where your consumers are reading from.

Terminal

kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --describe

Expected Output

TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                    HOST            CLIENT-ID

my-topic       0          15              20              5               consumer-1-1234abcd-5678-90ef-ghij-klmnopqrstuv /127.0.0.1      consumer-1

→

--bootstrap-server - Specifies the Kafka server address to connect to.

→

--group - Specifies the consumer group to inspect.

→

--describe - Shows detailed offset and lag information.

This command resets the offsets for 'my-group' on 'my-topic' to the earliest available messages, so the consumer will reprocess all messages from the start.

Terminal

kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --reset-offsets --to-earliest --topic my-topic --execute

Expected Output

Offsets reset to earliest for group my-group on topic my-topic.



Consumer group offsets have been reset successfully.

→

--reset-offsets - Starts the offset reset operation.

→

--to-earliest - Resets offsets to the earliest message available.

→

--execute - Applies the reset changes. Without this, the command only shows what would happen.

After resetting offsets, this command verifies the new offset positions to confirm the reset worked.

Terminal

kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --describe

Expected Output

TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                    HOST            CLIENT-ID

my-topic       0          0               20              20              -                                           -               -

→

--bootstrap-server - Specifies the Kafka server address to connect to.

→

--group - Specifies the consumer group to inspect.

→

--describe - Shows detailed offset and lag information.

Key Concept

If you remember nothing else from this pattern, remember: offsets tell your consumer where to start reading next to avoid missing or repeating messages.

Common Mistakes

Not using the --execute flag when resetting offsets.

Without --execute, the reset command only simulates the change and does not apply it.

Always add --execute to apply offset reset changes.

Resetting offsets without stopping the consumer group.

Active consumers may interfere with offset reset, causing inconsistent behavior.

Stop consumers in the group before resetting offsets, then restart them.

Confusing consumer group offsets with topic log end offsets.

Consumer offsets track reading position; log end offsets show total messages. Mixing them leads to wrong assumptions about lag.

Use the describe command to see both and understand lag as the difference.

Summary

Use kafka-consumer-groups --describe to check current offsets and lag for a consumer group.

Use kafka-consumer-groups --reset-offsets with --execute to change where a consumer group starts reading.

Always verify offset changes by describing the consumer group again after reset.

Practice

1. What is the main purpose of offset management in Kafka?

easy

A. To track which messages have been read by a consumer

B. To store the actual message data in Kafka topics

C. To manage the number of partitions in a topic

D. To control the replication factor of Kafka brokers

Solution

1. Step 1: Understand offset management role

   Offset management keeps track of the last message a consumer has read in a partition.

2. Step 2: Differentiate from other Kafka features

   Storing messages, partition count, and replication are unrelated to offset tracking.

3. Final Answer:

   To track which messages have been read by a consumer -> Option A

4. Quick Check:

   Offset management = track read messages [OK]

Hint: Offset management tracks read messages, not data storage [OK]

Common Mistakes:

• Confusing offset with message storage
• Mixing offset with partition or replication management
• Thinking offset controls message content

2. Which of the following is the correct way to manually commit offsets in Kafka consumer API?

easy

A. consumer.offsetCommit()

B. consumer.commitOffset()

C. consumer.saveOffset()

D. consumer.commitSync()

Solution

1. Step 1: Recall Kafka consumer API methods

   The official method to commit offsets manually is commitSync() or commitAsync().

2. Step 2: Identify the exact method name

   Only commitSync() matches the correct Kafka API method for synchronous commit.

3. Final Answer:

   consumer.commitSync() -> Option D

4. Quick Check:

   Manual commit method = commitSync() [OK]

Hint: Manual commit uses commitSync() or commitAsync() [OK]

Common Mistakes:

• Using incorrect method names like commitOffset()
• Confusing commitSync() with offsetCommit()
• Assuming saveOffset() exists

3. Given the following code snippet, what will be the output if the consumer seeks to offset 5 and reads one message?

consumer.assign(Collections.singleton(topicPartition));
consumer.seek(topicPartition, 5);
ConsumerRecords records = consumer.poll(Duration.ofMillis(1000));
for (ConsumerRecord record : records) {
    System.out.println(record.offset());
    break;
}

medium

A. 5

B. 0

C. 1

D. Exception thrown

Solution

1. Step 1: Understand seek behavior

   Calling seek sets the consumer's position to offset 5 in the assigned partition.

2. Step 2: Poll and print offset

   The poll fetches messages starting at offset 5; printing record.offset() outputs 5.

3. Final Answer:

   5 -> Option A

4. Quick Check:

   seek to 5 then poll = offset 5 [OK]

Hint: seek sets start offset; first polled message offset matches [OK]

Common Mistakes:

• Assuming poll starts from offset 0
• Expecting offset 1 instead of 5
• Thinking seek causes an exception

4. What is wrong with the following code snippet for committing offsets manually?

consumer.poll(Duration.ofMillis(1000));
consumer.commitAsync();
consumer.close();

medium

A. consumer.close() should be called before commitAsync()

B. commitAsync() should be called before poll()

C. commitAsync() is called without processing polled records

D. poll() duration is too short for commitAsync()

Solution

1. Step 1: Check offset commit timing

   Offsets should be committed after processing records, not just after poll().

2. Step 2: Identify missing processing step

   The code commits offsets without handling any messages, so it commits offsets that may not be processed.

3. Final Answer:

   commitAsync() is called without processing polled records -> Option C

4. Quick Check:

   Commit after processing, not just after poll [OK]

Hint: Always process records before committing offsets [OK]

Common Mistakes:

• Calling commit before processing messages
• Closing consumer before committing
• Misunderstanding poll duration effect

5. You want to restart a Kafka consumer and continue reading from the last committed offset, but also have the option to start from the beginning if no offset is found. Which approach correctly manages offsets to achieve this?

hard

A. Always call consumer.seekToEnd() before polling messages

B. Use consumer.seekToBeginning() if no committed offset exists, else start from committed offset

C. Manually set offset to 0 every time before polling

D. Disable offset commits and rely on auto.offset.reset = latest

Solution

1. Step 1: Understand offset reset behavior

   If no committed offset exists, consumer can seek to beginning to read all messages.

2. Step 2: Combine offset check and seek

   Check for committed offset; if found, start there; if not, call seekToBeginning() to start fresh.

3. Final Answer:

   Use consumer.seekToBeginning() if no committed offset exists, else start from committed offset -> Option B

4. Quick Check:

   Seek beginning if no offset, else resume from committed [OK]

Hint: Seek beginning only if no committed offset found [OK]

Common Mistakes:

• Always seeking to end loses old messages
• Resetting offset to 0 blindly every time
• Disabling commits causes loss of progress