Event streaming concept in Kafka - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a Kafka producer.

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", [1]);
KafkaProducer<String, String> producer = new KafkaProducer<>(props);

Drag options to blanks, or click blank then click option'

A"org.apache.kafka.common.serialization.StringSerializer"

B"org.apache.kafka.common.serialization.IntegerSerializer"

C"org.apache.kafka.common.serialization.ByteArraySerializer"

D"org.apache.kafka.common.serialization.LongSerializer"

Attempts:

3 left

💡 Hint

Common Mistakes

Using IntegerSerializer when sending strings causes errors.

Forgetting to set the value serializer.

The value serializer must be set to StringSerializer to send string messages.

2fill in blank

medium

Complete the code to send a message to a Kafka topic.

Kafka

ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", [1], "Hello Kafka");
producer.send(record);

Drag options to blanks, or click blank then click option'

A"value1"

Bnull

C"key1"

D"my-key"

Attempts:

3 left

💡 Hint

Common Mistakes

Using the message value as the key.

Passing null when a key is expected.

The second argument is the message key, which should be a string like "key1".

3fill in blank

hard

Fix the error in the consumer configuration to read string messages.

Kafka

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "test-group");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", [1]);
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

Drag options to blanks, or click blank then click option'

A"org.apache.kafka.common.serialization.StringDeserializer"

B"org.apache.kafka.common.serialization.IntegerDeserializer"

C"org.apache.kafka.common.serialization.ByteArrayDeserializer"

D"org.apache.kafka.common.serialization.LongDeserializer"

Attempts:

3 left

💡 Hint

Common Mistakes

Using IntegerDeserializer for string messages causes errors.

Not setting the value deserializer.

The value deserializer must be StringDeserializer to read string messages correctly.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that filters events with value length greater than 5.

Kafka

Map<String, String> filteredEvents = events.entrySet().stream()
    .filter(e -> e.getValue().[1]() > 5)
    .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));

Drag options to blanks, or click blank then click option'

Alength

Bcount

Csize

Dlength()

Attempts:

3 left

💡 Hint

Common Mistakes

Using length without parentheses causes errors.

Using size or count which are not string methods.

In Java, to get the length of a string, use the method length().

5fill in blank

hard

Fill all three blanks to create a Kafka consumer poll loop that processes records.

Kafka

while (true) {
    ConsumerRecords<String, String> records = consumer.[1](Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        System.out.println("Received message: " + record.[2]() + ": " + record.[3]());
    }
}

Drag options to blanks, or click blank then click option'

Apoll

Bkey

Cvalue

Dsubscribe

Attempts:

3 left

💡 Hint

Common Mistakes

Using subscribe instead of poll to fetch messages.

Accessing record fields directly instead of using methods.

The consumer uses poll() to fetch messages. Each record has key() and value() methods to access data.

Practice

1. What is the main purpose of event streaming in Kafka?

easy

A. To batch process data once a day

B. To store data permanently in a database

C. To create static reports from data

D. To send data as it happens for real-time updates

Solution

1. Step 1: Understand event streaming concept

   Event streaming means sending data continuously as events happen, not waiting to batch or store permanently.

2. Step 2: Match purpose with options

   Only To send data as it happens for real-time updates describes sending data as it happens for real-time updates, which is the core of event streaming.

3. Final Answer:

   To send data as it happens for real-time updates -> Option D

4. Quick Check:

   Event streaming = real-time data flow [OK]

Hint: Event streaming means data flows live, not stored or batched [OK]

Common Mistakes:

• Confusing event streaming with batch processing
• Thinking event streaming stores data permanently
• Assuming event streaming creates static reports

2. Which of the following is the correct way to describe a Kafka producer?

easy

A. A database that stores events permanently

B. A component that reads events from topics

C. A component that sends events to topics

D. A tool that visualizes event data

Solution

1. Step 1: Define Kafka producer role

   A Kafka producer is the part that sends or writes events into Kafka topics.

2. Step 2: Compare options with definition

   A component that sends events to topics correctly states the producer sends events to topics; others describe consumers, databases, or tools.

3. Final Answer:

   A component that sends events to topics -> Option C

4. Quick Check:

   Producer = sends events [OK]

Hint: Producer sends events; consumer reads events [OK]

Common Mistakes:

• Mixing up producer and consumer roles
• Thinking producer stores data permanently
• Confusing producer with visualization tools

3. Given this Kafka event flow: Producer sends events to topic 'orders'. Consumer reads from 'orders'. What happens if the consumer is slow?

medium

A. Events are lost immediately

B. Events accumulate in the topic until consumed

C. Producer stops sending events

D. Topic deletes old events instantly

Solution

1. Step 1: Understand Kafka topic behavior

   Kafka stores events in topics until consumers read them; slow consumers cause events to accumulate.

2. Step 2: Analyze options based on behavior

   Events accumulate in the topic until consumed matches this behavior; events wait in topic. Events are not lost immediately, producer keeps sending, and topic deletes old events only after retention period.

3. Final Answer:

   Events accumulate in the topic until consumed -> Option B

4. Quick Check:

   Slow consumer = event backlog in topic [OK]

Hint: Slow consumer causes event backlog, not loss [OK]

Common Mistakes:

• Assuming events are lost if consumer is slow
• Thinking producer stops sending events
• Believing topics delete events instantly

4. You wrote a Kafka consumer but it never receives any events. Which is the most likely mistake?

medium

A. The consumer is subscribed to the wrong topic

B. The producer is sending events correctly

C. The topic has too many partitions

D. The consumer is reading from the correct topic

Solution

1. Step 1: Identify why consumer gets no events

   If a consumer never receives events, a common cause is subscribing to the wrong topic.

2. Step 2: Evaluate options

   The consumer is subscribed to the wrong topic points to wrong topic subscription, which explains no events. Other options do not explain lack of events.

3. Final Answer:

   The consumer is subscribed to the wrong topic -> Option A

4. Quick Check:

   No events = wrong topic subscription [OK]

Hint: Check consumer topic subscription first [OK]

Common Mistakes:

• Ignoring topic subscription errors
• Blaming producer when it sends correctly
• Confusing topic partitions with event delivery

5. You want to build a real-time dashboard that updates instantly when new sales happen. Which Kafka setup best supports this?

hard

A. Producer sends sales events to a topic; consumer reads and updates dashboard immediately

B. Producer batches sales events daily; consumer reads once a day

C. Producer sends events to multiple unrelated topics; consumer reads only one

D. Consumer writes sales events back to producer

Solution

1. Step 1: Identify real-time update needs

   A real-time dashboard requires events sent and consumed instantly to update live.

2. Step 2: Match Kafka setup to real-time flow

   Producer sends sales events to a topic; consumer reads and updates dashboard immediately describes producer sending events to a topic and consumer reading immediately to update dashboard, fitting real-time needs.

3. Step 3: Eliminate other options

   Producer batches sales events daily; consumer reads once a day is batch, not real-time; C is inconsistent topic usage; D is incorrect flow direction.

4. Final Answer:

   Producer sends sales events to a topic; consumer reads and updates dashboard immediately -> Option A

5. Quick Check:

   Real-time dashboard = immediate event flow [OK]

Hint: Real-time needs immediate produce and consume flow [OK]

Common Mistakes:

• Choosing batch processing for real-time needs
• Using multiple unrelated topics incorrectly
• Confusing producer and consumer roles