Configuration best practices in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Kafka Producer Configuration Output

What will be the output of the following Kafka producer configuration code snippet when sending a message?

Kafka

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("acks", "all");
props.put("retries", 0);
props.put("batch.size", 16384);
props.put("linger.ms", 1);
props.put("buffer.memory", 33554432);
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", "key1", "value1");
producer.send(record, (metadata, exception) -> {
    if (exception == null) {
        System.out.println("Message sent to partition " + metadata.partition() + " with offset " + metadata.offset());
    } else {
        System.out.println("Error sending message: " + exception.getMessage());
    }
});
producer.close();

A No output because producer.send is asynchronous and program exits immediately

B Error sending message: UnknownTopicOrPartitionException

C Message sent to partition -1 with offset -1

D Message sent to partition 0 with offset 0

💡 Hint

Consider the default partitioning behavior and that the callback prints success or error.

The producer is configured correctly and sends a message to the topic 'my-topic'. Since no custom partitioner is set, the message goes to partition 0. The callback prints the partition and offset on success.

❓ Predict Output

intermediate

Kafka Consumer Configuration Behavior

Given this Kafka consumer configuration, what will be the value of the consumer's group.id after creation?

Kafka

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "1000");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
// Note: group.id is NOT set here

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
String groupId = consumer.groupMetadata().groupId();
System.out.println(groupId);

A Throws IllegalStateException

B default

C empty string

D null

💡 Hint

group.id is required for consumers to join a group.

Kafka consumer requires a group.id to be set. If it is missing, the consumer will throw an IllegalStateException when trying to access group metadata.

🧠 Conceptual

advanced

Best Practice for Kafka Broker Configuration

Which of the following is the best practice for configuring Kafka broker's log retention to balance disk usage and data availability?

A Set log.retention.hours to a reasonable time based on business needs and monitor disk usage

B Set log.retention.bytes to a small value to delete logs quickly

C Disable log retention and manually delete logs when disk is full

D Set log.retention.hours to a very high value and never delete old logs

💡 Hint

Think about balancing data availability and disk space.

Setting log retention to a reasonable time based on business needs ensures data is available for consumers while preventing disk from filling up. Monitoring disk usage helps adjust settings proactively.

❓ Predict Output

advanced

Effect of Incorrect Serializer Configuration

What will happen if a Kafka producer is configured with a StringSerializer for the key but an IntegerSerializer for the value, but the value sent is a String?

Kafka

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.IntegerSerializer");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", "key1", "value1");
producer.send(record);
producer.close();

A Message is sent successfully with value serialized as string

B Message is sent but value is null

C SerializationException is thrown at runtime

D Compile-time error due to type mismatch

💡 Hint

Check if the serializer matches the data type sent.

The IntegerSerializer expects Integer values. Sending a String causes a SerializationException at runtime.

🧠 Conceptual

expert

Optimizing Kafka Consumer Throughput

Which configuration change is most effective to increase Kafka consumer throughput when processing large volumes of messages?

A Set session.timeout.ms to a very low value to detect failures faster

B Set max.poll.records to a higher number and increase fetch.min.bytes

C Set enable.auto.commit to false and commit offsets manually after each message

D Set auto.offset.reset to earliest to always read from beginning

💡 Hint

Think about batch size and fetch size for throughput.

Increasing max.poll.records allows the consumer to fetch more messages per poll. Increasing fetch.min.bytes makes the broker wait to accumulate more data before responding. Both improve throughput.

Practice

1. Which of the following is a key benefit of following Kafka configuration best practices?

easy

A. Allows Kafka to run without any network connection

B. Automatic code generation for Kafka producers

C. Eliminates the need for monitoring Kafka brokers

D. Improved speed, safety, and reliability of Kafka clusters

Solution

1. Step 1: Understand Kafka configuration goals

   Kafka configs are designed to improve performance, safety, and reliability.

2. Step 2: Evaluate each option

   Only Improved speed, safety, and reliability of Kafka clusters correctly states the benefits of good Kafka configs.

3. Final Answer:

   Improved speed, safety, and reliability of Kafka clusters -> Option D

4. Quick Check:

   Kafka config benefits = Improved speed, safety, reliability [OK]

Hint: Remember: good configs make Kafka faster and safer [OK]

Common Mistakes:

• Thinking configs generate code automatically
• Assuming configs remove need for monitoring
• Believing Kafka works offline without network

2. Which of the following is the correct syntax to set a Kafka configuration property in a properties file?

easy

A. bootstrap.servers = localhost:9092

B. bootstrap.servers: localhost:9092

C. bootstrap.servers -> localhost:9092

D. bootstrap.servers localhost:9092

Solution

1. Step 1: Recall Kafka config file syntax

   Kafka uses key=value pairs in properties files.

2. Step 2: Match syntax to options

   Only bootstrap.servers = localhost:9092 uses the correct key=value format.

3. Final Answer:

   bootstrap.servers = localhost:9092 -> Option A

4. Quick Check:

   Kafka config syntax = key=value [OK]

Hint: Kafka configs use key=value pairs, not colons or arrows [OK]

Common Mistakes:

• Using colon instead of equals sign
• Using arrow symbols
• Omitting the equals sign

3. Given the following Kafka producer configuration snippet, what will be the value of acks used by the producer?

acks=all
retries=3
linger.ms=5

medium

A. "all" meaning the leader waits for all replicas to acknowledge

B. "0" meaning no acknowledgments are required

C. "1" meaning only the leader acknowledges

D. An error because "all" is not a valid value

Solution

1. Step 1: Understand the meaning of acks=all

   In Kafka, acks=all means leader waits for all replicas to confirm the message.

2. Step 2: Check options against this meaning

   "all" meaning the leader waits for all replicas to acknowledge correctly describes acks=all behavior.

3. Final Answer:

   "all" meaning the leader waits for all replicas to acknowledge -> Option A

4. Quick Check:

   acks=all means wait for all replicas [OK]

Hint: Remember: acks=all waits for all replicas to confirm [OK]

Common Mistakes:

• Confusing acks=all with acks=0 or acks=1
• Thinking 'all' is invalid
• Assuming no acknowledgments are needed

4. You have set log.retention.hours=168 in your Kafka broker config, but logs are not retained for 7 days as expected. What is a likely cause?

medium

A. The log.retention.hours value must be set in minutes

B. The log.retention.bytes setting is limiting retention by size

C. Kafka does not support retention configuration

D. The broker needs to be restarted for changes to take effect

Solution

1. Step 1: Understand retention config interaction

   Kafka retention can be limited by time or size; size limit can override time.

2. Step 2: Analyze options

   The log.retention.bytes setting is limiting retention by size correctly identifies size limit as a possible cause.

3. Final Answer:

   The log.retention.bytes setting is limiting retention by size -> Option B

4. Quick Check:

   Retention limited by size overrides time [OK]

Hint: Check size limits when time-based retention seems ignored [OK]

Common Mistakes:

• Assuming retention.hours must be in minutes
• Believing Kafka ignores retention settings
• Forgetting to restart broker (not always needed)

5. You want to safely update Kafka broker configurations without downtime. Which approach follows best practices?

hard

A. Update configs on all brokers simultaneously and restart all at once

B. Stop the entire Kafka cluster, update configs, then restart all brokers

C. Update configs on one broker at a time, restart it, then move to next

D. Change configs dynamically without any restarts or backups

Solution

1. Step 1: Understand safe config update practices

   Updating one broker at a time avoids cluster downtime and data loss.

2. Step 2: Evaluate options for safety and availability

   Update configs on one broker at a time, restart it, then move to next follows the best practice of rolling updates with restarts.

3. Final Answer:

   Update configs on one broker at a time, restart it, then move to next -> Option C

4. Quick Check:

   Rolling updates = safer config changes [OK]

Hint: Update brokers one by one to avoid downtime [OK]

Common Mistakes:

• Restarting all brokers simultaneously causing downtime
• Stopping entire cluster unnecessarily
• Changing configs without backups or restarts