Consumer offset commit strategies in Kafka - Commands & Configuration

Introduction

When a Kafka consumer reads messages, it needs to remember which messages it has processed. This is done by committing offsets. Different commit strategies help balance between processing speed and data safety.

When you want to ensure no message is processed twice even if the consumer crashes.

When you want faster processing and can tolerate some duplicate message processing.

When you want to commit offsets automatically without manual intervention.

When you want to control exactly when offsets are committed after processing messages.

When you want to avoid losing messages during consumer restarts.

Commands

Starts a Kafka consumer that automatically commits offsets every 5 seconds. This is the automatic commit strategy for convenience and speed.

Terminal

kafka-console-consumer --bootstrap-server localhost:9092 --topic example-topic --group example-group --enable-auto-commit true --auto-commit-interval-ms 5000

Expected Output

This will start printing messages from example-topic as they arrive.

Offsets will be committed automatically every 5 seconds.

→

--enable-auto-commit - Enables automatic offset commits.

→

--auto-commit-interval-ms - Sets how often offsets are committed automatically.

Starts a Kafka consumer with automatic commits disabled. This means you must commit offsets manually to control when messages are marked as processed.

Terminal

kafka-console-consumer --bootstrap-server localhost:9092 --topic example-topic --group example-group --enable-auto-commit false

Expected Output

This will start printing messages from example-topic as they arrive.

Offsets will not be committed automatically.

→

--enable-auto-commit - Disables automatic offset commits.

Shows the current committed offsets and lag for the consumer group. Useful to verify which messages have been processed and committed.

Terminal

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

Expected Output

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

example-topic  0          15              20              5    consumer-1-12345-67890                      /127.0.0.1      consumer-1

→

--group - Specifies the consumer group to inspect.

Key Concept

If you remember nothing else from this pattern, remember: committing offsets tells Kafka which messages you have processed, and choosing when to commit balances speed and safety.

Common Mistakes

Leaving auto-commit enabled but processing messages slowly without handling duplicates.

Offsets may be committed before processing finishes, causing message loss if the consumer crashes.

Disable auto-commit and commit offsets manually after processing each message or batch.

Disabling auto-commit but never committing offsets manually.

Kafka will think messages are unprocessed and resend them, causing duplicates.

Always commit offsets manually at appropriate points in your processing.

Committing offsets before processing messages.

If processing fails after commit, messages are lost and not retried.

Commit offsets only after successful processing.

Summary

Automatic offset commit lets Kafka track processed messages regularly without manual work.

Manual offset commit gives precise control to avoid message loss or duplicates.

Use kafka-consumer-groups command to check committed offsets and consumer lag.

Practice

1. What is the main purpose of committing consumer offsets in Kafka?

easy

A. To delete old messages from the topic

B. To increase the speed of message production

C. To create new topics automatically

D. To track which messages have been processed to avoid duplicates

Solution

1. Step 1: Understand consumer offset role

   Consumer offsets mark the position of the last processed message in a partition.

2. Step 2: Identify the purpose of committing offsets

   Committing offsets helps Kafka know where to resume reading after a restart, preventing duplicate processing.

3. Final Answer:

   To track which messages have been processed to avoid duplicates -> Option D

4. Quick Check:

   Offset commit = track processed messages [OK]

Hint: Offsets mark progress to avoid reprocessing messages [OK]

Common Mistakes:

• Confusing offset commit with message production speed
• Thinking offsets delete messages
• Believing offsets create topics

2. Which Kafka consumer configuration enables automatic offset commits?

easy

A. enable.auto.commit=false

B. auto.offset.reset=earliest

C. enable.auto.commit=true

D. auto.commit.interval.ms=0

Solution

1. Step 1: Identify the setting for automatic commits

   The setting enable.auto.commit controls if Kafka commits offsets automatically.

2. Step 2: Check the correct value to enable auto commit

   Setting it to true enables automatic offset commits.

3. Final Answer:

   enable.auto.commit=true -> Option C

4. Quick Check:

   enable.auto.commit=true means auto commit enabled [OK]

Hint: Look for enable.auto.commit=true to enable auto commits [OK]

Common Mistakes:

• Confusing auto.offset.reset with auto commit
• Setting enable.auto.commit to false expecting auto commit
• Misunderstanding auto.commit.interval.ms controls commit frequency, not enabling

3. Given this code snippet, what will be the output if the consumer commits offsets manually after processing 3 messages?

consumer.subscribe(["topic"])
for i in range(5):
    msg = consumer.poll(1000)
    print(f"Processing message {i}")
    if i == 2:
        consumer.commitSync()

medium

A. Processing message 0
Processing message 1
Processing message 2
Processing message 3
Processing message 4

B. Processing message 0
Processing message 1
Processing message 2

C. Processing message 0
Processing message 1
Processing message 2
Processing message 3

D. No output due to commit error

Solution

1. Step 1: Analyze the loop and commit timing

   The loop runs 5 times, printing "Processing message i" each time from 0 to 4.

2. Step 2: Understand commitSync effect

   Calling commitSync() at i=2 commits offsets but does not stop processing.

3. Final Answer:

   Processing message 0 Processing message 1 Processing message 2 Processing message 3 Processing message 4 -> Option A

4. Quick Check:

   commitSync commits but loop continues [OK]

Hint: commitSync doesn't stop processing; loop runs fully [OK]

Common Mistakes:

• Assuming commitSync stops the loop
• Thinking only messages before commit are processed
• Confusing commitSync with commitAsync behavior

4. Identify the error in this Kafka consumer code snippet related to offset commits:

consumer.subscribe(["topic"])
while True:
    msg = consumer.poll(1000)
    if msg is not None:
        process(msg)
    consumer.commitAsync()

medium

A. poll() should not have a timeout

B. commitAsync() is called outside the message check, causing commits even when no message is received

C. process(msg) should be called after commitAsync()

D. subscribe() must be called inside the loop

Solution

1. Step 1: Review commitAsync placement

   commitAsync() is called every loop iteration, even if no message is received.

2. Step 2: Understand why this is a problem

   Committing offsets without processing messages can commit the same offset repeatedly or cause unexpected behavior.

3. Final Answer:

   commitAsync() is called outside the message check, causing commits even when no message is received -> Option B

4. Quick Check:

   commitAsync outside message check causes wrong commits [OK]

Hint: Call commit only after processing a message [OK]

Common Mistakes:

• Calling commitAsync regardless of message presence
• Moving subscribe inside the loop unnecessarily
• Misordering process and commit calls

5. You want to ensure your Kafka consumer starts reading from the earliest offset if no committed offset exists, but commits offsets manually only after processing batches of 10 messages. Which configuration and strategy combination is correct?

hard

A. Set auto.offset.reset to earliest and disable enable.auto.commit, then call commitSync() after every 10 messages

B. Set auto.offset.reset to latest and enable enable.auto.commit, commit automatically every 10 messages

C. Set auto.offset.reset to earliest and enable enable.auto.commit, commit manually after every message

D. Set auto.offset.reset to none and disable enable.auto.commit, never commit offsets

Solution

1. Step 1: Choose offset reset policy

   Setting auto.offset.reset to earliest ensures reading from the start if no offset exists.

2. Step 2: Select commit strategy

   Disabling enable.auto.commit allows manual control; calling commitSync() after 10 messages commits offsets in batches.

3. Final Answer:

   Set auto.offset.reset to earliest and disable enable.auto.commit, then call commitSync() after every 10 messages -> Option A

4. Quick Check:

   earliest + manual commit after batch = correct strategy [OK]

Hint: earliest + manual commit after batch = safe and controlled [OK]

Common Mistakes:

• Using latest offset reset when earliest is needed
• Enabling auto commit but expecting manual control
• Not committing offsets causing reprocessing