KStream and KTable concepts in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this KStream aggregation?

Consider a KStream that reads user clicks and counts clicks per user. What will be the output after aggregation?

Kafka

KStream<String, String> clicks = builder.stream("clicks-topic");
KTable<String, Long> clickCounts = clicks.groupByKey().count();
clickCounts.toStream().foreach((user, count) -> System.out.println(user + ": " + count));

A Throws a runtime error because count() is not valid on KStream

B Prints only the first click per user and stops updating

C Prints all clicks without aggregation

D Prints each user with their total click count, updating as new clicks arrive

💡 Hint

Think about how KTable represents aggregated state and updates.

KTable stores the latest aggregated value per key. The count() operation groups clicks by user and counts them, updating the count as new clicks arrive. The toStream() converts the KTable back to a stream of updates.

🧠 Conceptual

intermediate

Difference between KStream and KTable

Which statement correctly describes the difference between KStream and KTable?

A KStream represents a stream of immutable events; KTable represents a changelog stream of updates to a table

B KStream stores the latest value per key; KTable stores all events without aggregation

C KStream is used only for input; KTable is used only for output

D KStream and KTable are identical and interchangeable

💡 Hint

Think about how data changes over time in each abstraction.

KStream is a sequence of immutable events, each event is independent. KTable represents a table where each key has a current value that can be updated, so it is a changelog stream.

🔧 Debug

advanced

Why does this KTable join produce no output?

Given two KTables joined on key, why does the join produce no output?

Kafka

KTable<String, String> table1 = builder.table("topic1");
KTable<String, String> table2 = builder.table("topic2");
KTable<String, String> joined = table1.join(table2, (v1, v2) -> v1 + v2);
joined.toStream().foreach((k,v) -> System.out.println(k + ": " + v));

A Because the topics "topic1" and "topic2" have no overlapping keys

B Because the join function returns null

C Because join() is not supported on KTables

D Because toStream() does not convert KTable to a stream

💡 Hint

Think about what keys must exist in both tables for a join to produce output.

A KTable join produces output only for keys present in both tables. If the topics have no overlapping keys, no joined records are emitted.

📝 Syntax

advanced

Identify the syntax error in this KStream filter code

Which option contains the correct syntax to filter a KStream for values starting with "error"?

Kafka

KStream<String, String> logs = builder.stream("logs-topic");
KStream<String, String> errors = logs.filter((key, value) -> value.startsWith("error"));

A logs.filter((k, v) -> { return value.startsWith("error"); });

B logs.filter(key, value -> value.startsWith("error"));

C logs.filter((key, value) -> value.startsWith("error"));

D logs.filter((key, value) => value.startsWith("error"));

💡 Hint

Check the lambda syntax and parameter usage in Java.

Option C uses correct Java lambda syntax with parentheses around parameters and arrow ->. Option C misses parentheses. Option C uses JavaScript arrow syntax. Option C uses undefined variable 'value' inside lambda.

🚀 Application

expert

How many items are in the resulting KTable after this aggregation?

Given a KStream of orders keyed by orderId, this code groups by customerId and counts orders per customer. How many entries will the resulting KTable have if there are 1000 orders from 100 distinct customers?

Kafka

KStream<String, Order> orders = builder.stream("orders-topic");
KTable<String, Long> ordersPerCustomer = orders.groupBy((orderId, order) -> order.getCustomerId()).count();

A 1000

B 100

C 0

D Depends on the order of processing

💡 Hint

Think about grouping by customerId and counting orders per customer.

The groupBy changes the key to customerId, so the count aggregates orders per customer. Since there are 100 distinct customers, the KTable will have 100 entries.