Idempotent producer in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output when sending messages with idempotent producer enabled?

Consider the following Kafka producer configuration and code snippet. What will be the output in the Kafka topic after running this code?

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.StringSerializer");
props.put("enable.idempotence", "true");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

for (int i = 0; i < 3; i++) {
    producer.send(new ProducerRecord<>("my-topic", "key1", "message"));
}
producer.flush();
producer.close();

A The topic will contain 3 identical messages with key 'key1' and value 'message'.

B The topic will contain 1 message with key 'key1' and value 'message' because idempotence prevents duplicates.

C The topic will contain no messages because the producer is idempotent and suppresses all sends.

D The code will throw a runtime exception because sending multiple messages with the same key is not allowed.

💡 Hint

Idempotent producer prevents duplicates caused by retries, not multiple sends in the same session.

Idempotent producer ensures that retries of the same message do not result in duplicates. However, sending the same message multiple times intentionally will produce multiple messages in the topic.

❓ Predict Output

intermediate

What error occurs if 'enable.idempotence' is set to false but 'acks' is set to 'all'?

Given the following Kafka producer configuration, what will happen when sending messages?

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.StringSerializer");
props.put("enable.idempotence", "false");
props.put("acks", "all");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("my-topic", "key", "value"));
producer.flush();
producer.close();

A The producer sends messages but with a warning logged about inconsistent configuration.

B The producer throws a ConfigException because 'acks=all' requires 'enable.idempotence=true'.

C The producer silently enables idempotence despite the configuration to ensure data safety.

D The producer sends messages successfully with full acknowledgment but without idempotence guarantees.

💡 Hint

Idempotence and acks are related but not strictly dependent in Kafka configuration.

'acks=all' means the leader waits for all replicas to acknowledge. Idempotence is optional and disabled here, so messages send successfully but without idempotent guarantees.

🔧 Debug

advanced

Why does this idempotent producer code cause duplicate messages after a network failure?

Examine the code below. Despite enabling idempotence, duplicate messages appear in the topic after a network failure. What is the cause?

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.StringSerializer");
props.put("enable.idempotence", "true");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

for (int i = 0; i < 5; i++) {
    producer.send(new ProducerRecord<>("my-topic", "key", "message"));
    if (i == 2) {
        // Simulate network failure by closing producer abruptly
        producer.close();
        producer = new KafkaProducer<>(props);
    }
}
producer.flush();
producer.close();

A Idempotence only works within a single producer instance; closing and reopening resets sequence numbers causing duplicates.

B The producer configuration is missing 'acks=all', so duplicates occur despite idempotence.

C The topic is configured with multiple partitions, so duplicates are expected with idempotence enabled.

D The key serializer is incorrect, causing messages to be treated as different keys and duplicated.

💡 Hint

Idempotence tracks sequence numbers per producer instance to avoid duplicates.

When the producer is closed and reopened, it loses its sequence number state. This causes Kafka to treat messages as new and duplicates can occur after retries.

📝 Syntax

advanced

Which Kafka producer configuration snippet correctly enables idempotence with safe retries?

Select the configuration snippet that correctly enables idempotence and configures retries safely.

A props.put("enable.idempotence", true); props.put("retries", -1); props.put("acks", "1");

B props.put("enable.idempotence", "true"); props.put("retries", Integer.MAX_VALUE); props.put("acks", "all");

C props.put("enable.idempotence", "false"); props.put("retries", 5); props.put("acks", "all");

D props.put("enable.idempotence", "true"); props.put("retries", 0); props.put("acks", "all");

💡 Hint

Idempotence requires 'acks=all' and retries enabled to be effective.

Option B correctly sets 'enable.idempotence' to string "true", retries to max integer, and 'acks' to 'all'. Option B uses invalid retries (-1) and 'acks' to '1'. Option B disables idempotence. Option B disables retries.

🚀 Application

expert

How to ensure exactly-once semantics in Kafka producer with idempotence enabled?

You want to guarantee that messages are delivered exactly once to a Kafka topic using an idempotent producer. Which approach below correctly achieves this?

A Enable idempotence and set 'acks' to '1' to reduce latency and rely on retries for duplicates.

B Disable idempotence but use manual offset commits in the consumer to avoid duplicates.

C Enable idempotence, set 'acks' to 'all', configure infinite retries, and use transactions to commit messages atomically.

D Enable idempotence and set 'retries' to 0 to avoid resending messages and duplicates.

💡 Hint

Exactly-once semantics require atomic writes and idempotent producer with proper acknowledgments.

Exactly-once delivery requires idempotence, 'acks=all', infinite retries to handle failures, and transactions to atomically commit messages. Other options either reduce reliability or do not guarantee exactly-once.