Why advanced patterns handle complex flows in Kafka - Challenge Your Understanding

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Kafka Streams code snippet?

Consider this Kafka Streams Java code that processes a stream of user clicks and counts clicks per user in a 1-minute window. What will be the output printed to the console?

Kafka

StreamsBuilder builder = new StreamsBuilder();
KStream<String, String> clicks = builder.stream("clicks-topic");
KTable<Windowed<String>, Long> clickCounts = clicks
  .groupByKey()
  .windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofMinutes(1)))
  .count();
clickCounts.toStream().foreach((windowedUser, count) -> {
  System.out.println(windowedUser.key() + "@" + windowedUser.window().start() + ": " + count);
});

A Prints user IDs with counts for each 1-minute window, e.g., user1@1672531200000: 5

B Prints total counts per user without window info, e.g., user1: 5

C Prints counts but throws a runtime exception due to missing Serdes

D Prints counts but only for the last window, ignoring earlier ones

💡 Hint

Think about how windowed aggregations include window info in the key.

The code groups clicks by user key and counts them in 1-minute windows. The output includes the user ID and the window start timestamp, showing counts per window.

🧠 Conceptual

intermediate

Why use advanced Kafka patterns like exactly-once semantics?

Which reason best explains why advanced Kafka patterns such as exactly-once semantics are important in complex data flows?

A To allow messages to be lost safely without affecting downstream systems

B To ensure messages are processed only once, avoiding duplicates in critical financial transactions

C To reduce the number of partitions in a topic for simpler management

D To speed up message delivery by skipping acknowledgments

💡 Hint

Think about data accuracy and consistency in important systems.

Exactly-once semantics guarantee that each message is processed once and only once, which is crucial for systems like payments where duplicates cause errors.

🔧 Debug

advanced

Identify the error in this Kafka Streams topology code

This code snippet attempts to join two streams but throws an exception at runtime. What is the cause?

Kafka

StreamsBuilder builder = new StreamsBuilder();
KStream<String, String> stream1 = builder.stream("topic1");
KStream<String, String> stream2 = builder.stream("topic2");
KStream<String, String> joined = stream1.join(stream2,
  (v1, v2) -> v1 + ":" + v2,
  JoinWindows.ofTimeDifferenceWithNoGrace(Duration.ofSeconds(30))
);
joined.to("joined-topic");

A Streams must be grouped before joining, so join() call is invalid

B JoinWindows.ofTimeDifferenceWithNoGrace is deprecated and causes compile error

C Missing Serdes configuration causes serialization error during join

D The join function must return a boolean, not a string

💡 Hint

Check if serializers and deserializers are properly set for keys and values.

Kafka Streams requires proper Serdes for keys and values to serialize data during joins. Missing or wrong Serdes cause runtime serialization exceptions.

📝 Syntax

advanced

Which option correctly defines a Kafka Streams topology with a filter and map operation?

Select the code snippet that compiles and runs without errors, applying a filter and map on a KStream.

A builder.stream("input-topic").filter((k,v) -> v.length() > 3).map((k,v) -> KeyValue.pair(k, v.toUpperCase()));

B builder.stream("input-topic").filter(k,v -> v.length() > 3).map((k,v) -> KeyValue.pair(k, v.toUpperCase()));

C builder.stream("input-topic").filter((k,v) -> v.length() > 3).map((k,v) -> (k, v.toUpperCase()));

D builder.stream("input-topic").filter((k,v) -> {v.length() > 3}).map((k,v) -> KeyValue.pair(k, v.toUpperCase()));

💡 Hint

Check lambda syntax and return types for filter and map.

Option A uses correct lambda syntax with parentheses and returns a KeyValue pair in map. Others have syntax errors or wrong return types.

🚀 Application

expert

How does the Kafka Streams Processor API handle complex event flows differently from the DSL?

Which statement best describes the advantage of using the Processor API over the DSL for complex Kafka event processing?

A Processor API disables fault tolerance to improve speed in complex flows

B Processor API automatically optimizes joins and aggregations without user code

C Processor API requires less code and is easier for simple filtering tasks

D Processor API allows fine-grained control over processing logic and state management beyond DSL capabilities

💡 Hint

Think about customization and control in processing pipelines.

Processor API lets developers write custom processors with direct access to state stores and event context, enabling complex logic not possible with DSL.