Auto-commit vs manual commit in Kafka - Performance Comparison
When working with Kafka consumers, committing offsets is key to tracking what messages have been processed.
We want to understand how auto-commit and manual commit affect the time it takes to process messages as the input grows.
Analyze the time complexity of these two commit styles in Kafka consumer code.
// Auto-commit example
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "1000");
// Manual commit example
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<String, String> record : records) {
process(record);
}
consumer.commitSync();
}
The first uses automatic commits at intervals, the second commits manually after processing each batch.
Look at what repeats as messages increase.
- Primary operation: Processing each message in the batch (loop over records).
- How many times: Once per message received in both cases.
- Commit operation: Auto-commit runs periodically in background; manual commit runs once per batch after processing.
Processing time grows with the number of messages because each message is handled once.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Process 10 messages + few commits |
| 100 | Process 100 messages + few commits |
| 1000 | Process 1000 messages + few commits |
Pattern observation: Processing grows linearly with messages; commits happen less often and do not grow with message count.
Time Complexity: O(n)
This means the time to process messages grows directly with the number of messages, while commit overhead stays small.
[X] Wrong: "Manual commit makes processing slower because it commits every message."
[OK] Correct: Manual commit usually happens once per batch, not per message, so it does not slow down processing linearly.
Understanding how commit strategies affect processing time helps you explain trade-offs clearly in real projects.
What if we commit manually after every single message instead of after the batch? How would the time complexity change?
Practice
Solution
Step 1: Understand auto-commit behavior
Auto-commit commits offsets automatically at regular intervals without user intervention.Step 2: Understand manual commit behavior
Manual commit requires the consumer to explicitly call commit() after processing messages.Final Answer:
Auto-commit commits offsets automatically at intervals, manual commit requires explicit commit calls. -> Option CQuick Check:
Auto-commit = automatic, Manual commit = explicit call [OK]
- Confusing which method commits automatically
- Thinking manual commit disables offset tracking
- Believing auto-commit commits only on shutdown
Solution
Step 1: Identify the correct config key
The correct Kafka consumer config key to control auto-commit is "enable.auto.commit".Step 2: Identify the correct value to disable auto-commit
Setting "enable.auto.commit" to false disables auto-commit.Final Answer:
"enable.auto.commit" : false -> Option AQuick Check:
Disable auto-commit = enable.auto.commit = false [OK]
- Using wrong config key names
- Setting true instead of false to disable
- Using string values instead of boolean
consumer.poll(Duration.ofMillis(100)).forEach(record -> {
process(record);
});
consumer.commitSync();
What happens if commitSync() is called before processing the records?Solution
Step 1: Understand commitSync timing
commitSync() commits the current offsets to Kafka immediately when called.Step 2: Analyze calling commitSync before processing
If commitSync() is called before processing, offsets are saved before messages are handled, risking data loss if processing fails.Final Answer:
Offsets are committed before processing, risking message loss on failure. -> Option AQuick Check:
Commit before processing = risk of message loss [OK]
- Assuming commitSync waits for processing
- Thinking commitSync throws error if called early
- Believing offsets commit automatically without call
Solution
Step 1: Check manual commit requirements
When auto-commit is disabled, the consumer must call commit() explicitly after processing.Step 2: Identify cause of missing commits
If offsets are not committed, likely commit() was not called after processing, causing reprocessing.Final Answer:
You forgot to call commit() after processing messages. -> Option DQuick Check:
Manual commit needs explicit commit() call [OK]
- Assuming auto-commit still works when disabled
- Blaming Kafka broker without checking code
- Calling commit() before processing messages
Solution
Step 1: Understand exactly-once processing needs
Exactly-once means processing each message once and committing offset only after success.Step 2: Compare commit strategies
Auto-commit commits offsets automatically at intervals, risking committing before processing completes. Manual commit lets you commit only after successful processing.Final Answer:
Manual commit, because you commit offsets only after successful processing. -> Option BQuick Check:
Exactly-once needs manual commit after success [OK]
- Assuming auto-commit guarantees exactly-once
- Committing offsets before processing
- Ignoring commit timing importance
Ready to prove it?
Pass the test and this pattern moves unknown
