Why consumers process messages in Kafka - Performance Analysis
When Kafka consumers process messages, the time it takes depends on how many messages they handle.
We want to understand how the work grows as more messages arrive.
Analyze the time complexity of the following code snippet.
consumer.poll(Duration.ofMillis(100)).forEach(record -> {
process(record);
});
This code polls messages from Kafka and processes each one in a loop.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each message received in the poll.
- How many times: Once for every message in the batch.
As the number of messages increases, the processing time grows proportionally.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 process calls |
| 100 | 100 process calls |
| 1000 | 1000 process calls |
Pattern observation: The work grows directly with the number of messages.
Time Complexity: O(n)
This means the time to process messages grows in a straight line as more messages come in.
[X] Wrong: "Processing one message takes the same time no matter how many messages there are."
[OK] Correct: Each message adds extra work, so total time grows with the number of messages.
Understanding how message processing time grows helps you explain system behavior clearly and shows you can think about performance in real situations.
"What if the consumer processed messages in parallel instead of one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of consumers in Kafka
Consumers read messages produced by producers to get data for processing.Step 2: Identify the purpose of processing messages
Processing messages allows applications to react to new information sent by producers.Final Answer:
To read and use data sent by producers -> Option BQuick Check:
Consumers read messages = To use data [OK]
- Thinking consumers send messages
- Confusing consumers with producers
- Believing consumers delete messages
orders in Java?Solution
Step 1: Recall Kafka consumer subscription syntax in Java
The consumer.subscribe method expects a collection of topic names, usually a list.Step 2: Check each option's syntax
consumer.subscribe(Collections.singletonList("orders")); uses Collections.singletonList("orders"), which is correct. Options A, B, and D use incorrect methods or argument types.Final Answer:
consumer.subscribe(Collections.singletonList("orders")); -> Option DQuick Check:
subscribe needs a list of topics [OK]
- Passing a string instead of a list
- Using non-existent methods like listen or connect
- Forgetting to import Collections
from kafka import KafkaConsumer
consumer = KafkaConsumer('test-topic', bootstrap_servers=['localhost:9092'])
for message in consumer:
print(message.value.decode('utf-8'))
breakSolution
Step 1: Understand the consumer loop behavior
The for loop reads messages from 'test-topic' one by one.Step 2: Analyze the print and break statements
The first message's value is decoded from bytes to string and printed, then the loop breaks immediately.Final Answer:
The first message's value from 'test-topic' decoded as UTF-8 -> Option AQuick Check:
Print first message then break = first message only [OK]
- Thinking all messages print
- Confusing decode method usage
- Assuming no output due to break
KafkaConsumer consumer = new KafkaConsumer<>(props);
consumer.subscribe("my-topic");
while(true) {
ConsumerRecords records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord record : records) {
System.out.println(record.value());
}
}Solution
Step 1: Check the subscribe method usage
In Kafka Java client, subscribe expects a collection of topic names, not a single string.Step 2: Verify other code parts
poll with Duration is correct, ConsumerRecord has value(), and while(true) is valid for continuous consumption.Final Answer:
subscribe method requires a collection, not a single string -> Option CQuick Check:
subscribe needs list of topics [OK]
- Passing a string directly to subscribe
- Misunderstanding poll method arguments
- Thinking ConsumerRecord lacks value()
Solution
Step 1: Understand offset reset behavior
Setting "auto.offset.reset" to "latest" makes the consumer start reading from the newest messages if no committed offset exists.Step 2: Evaluate other options
"enable.auto.commit" controls offset commits, "group.id" identifies consumer groups, and "max.poll.records" limits batch size but doesn't affect starting offset.Final Answer:
"auto.offset.reset" to "latest" -> Option AQuick Check:
Start from latest messages = auto.offset.reset=latest [OK]
- Confusing offset reset with auto commit
- Changing group.id to control offset start
- Using max.poll.records to control offset
Ready to prove it?
Pass the test and this pattern moves unknown
