Kafka Streams Basics

Analogy categoryAnalogies

What Is Kafka Streams?

Kafka Streams is a Java client library, not a separate cluster or framework you deploy: it lets you write standalone applications that read from input topics, transform records, and write results to output topics using the same JVM process as your business logic. Because it is 'just a library,' scaling a Streams application is as simple as running more instances of the same JAR, and Kafka's consumer group protocol automatically divides the input topic's partitions among the running instances.

🏏

Cricket analogy: It is like a team where every fielder already knows their position from the toss lineup card, rather than needing a separate umpire's office to coordinate them, the way MS Dhoni set his field without external management during a Chennai Super Kings run-chase.

The Streams DSL: KStream, KTable, and Topology

The Streams DSL gives you two core abstractions: a KStream, which represents an unbounded sequence of independent events (think of each record as a fact that happened), and a KTable, which represents a changelog-backed table where each new record with the same key overwrites the previous value. Chaining operators like filter, map, groupByKey, and join builds a processor topology, a directed graph of source, processing, and sink nodes that Kafka Streams compiles under the hood and distributes across tasks.

🏏

Cricket analogy: A KStream is like the ball-by-ball commentary feed of a match, every delivery is a distinct event, while a KTable is like the current scoreboard, where only the latest total for each team matters and old totals are overwritten.

Stateful Processing and State Stores

Operations like aggregate, count, and reduce require Kafka Streams to remember state across records, so the library maintains local state stores, typically backed by embedded RocksDB, on each task instance. To make this state fault-tolerant, every change to a state store is also written to an internal, compacted changelog topic in Kafka; if an instance crashes, a replacement task can rebuild its RocksDB store by replaying that changelog rather than losing the aggregation entirely.

🏏

Cricket analogy: It is like a scorer who keeps a running tally in a private notebook (the local store) but also phones the result to the official scoreboard operator after every over (the changelog), so if the scorer's notebook is lost, the official log can reconstruct it.

Scaling with Tasks and Partitions

Kafka Streams parallelizes work by dividing the topology into tasks, one task per input partition group, and assigning tasks across whatever application instances are currently running, coordinated through the same consumer group rebalance protocol used by plain consumers. This means the maximum parallelism of a Streams application is bounded by the partition count of its input topics: adding a sixth instance when the source topic only has five partitions leaves that sixth instance idle.

🏏

Cricket analogy: It is like a five-bowler rotation in an ODI, no matter how many extra bowlers you bring to the ground, only five overs slots exist per innings phase, so a sixth bowler simply sits out.

java

StreamsBuilder builder = new StreamsBuilder();

KStream<String, String> textLines = builder.stream("input-topic");

KTable<String, Long> wordCounts = textLines
    .flatMapValues(line -> Arrays.asList(line.toLowerCase().split("\\W+")))
    .groupBy((key, word) -> word)
    .count(Materialized.as("word-counts-store"));

wordCounts.toStream().to("output-topic", Produced.with(Serdes.String(), Serdes.Long()));

Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "word-count-app");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.PROCESSING_GUARANTEE_CONFIG, StreamsConfig.EXACTLY_ONCE_V2);

KafkaStreams streams = new KafkaStreams(builder.build(), props);
streams.start();

Setting processing.guarantee to exactly_once_v2 enables transactional writes across the consume-process-produce cycle, so a task failure and restart won't duplicate output records even though input records may still be reprocessed internally.

Because state stores are rebuilt from changelog topics on failover, an application with large aggregation state can take a noticeable amount of time to restore after a rebalance; enabling standby replicas (num.standby.replicas) keeps a warm copy of the store on another instance to cut this restoration time.

Kafka Streams is a client library embedded in your application, not a separate processing cluster.
KStream models an unbounded sequence of independent events; KTable models a changelog-backed, continuously updated table.
Stateful operators use local RocksDB-backed state stores, backed by fault-tolerant, compacted changelog topics.
Parallelism is bounded by the number of input partitions, since each task maps to one partition group.
Rebalancing uses the same consumer group protocol as plain Kafka consumers to redistribute tasks.
Standby replicas reduce recovery time after a failover by keeping warm copies of state stores.
exactly_once_v2 uses Kafka transactions to guarantee no duplicate output on task restarts.