A processing node is a step in a Kafka Streams topology: a directed graph that moves key-value records from source nodes through one or more transformations to sink nodes. Each node performs a distinct operation and forwards records to its child nodes; a node can also receive input from multiple parents. section 6.0 section 6.3.1
Figure 6.1 Kafka Streams is a graph with a source node, any number of processing nodes, and a sink node.
Use the topology diagram to distinguish source, processing, and sink nodes and follow the direction of record flow. section 6.1
In the Kafka Streams DSL, each operation adds a node. Calling mapValues creates a child processing node whose input comes from the source node; it changes only the record value and forwards the original key. More generally, map can replace both key and value, while filter, branch, merge, selectKey, peek, and print establish other processing behavior. section 6.3.1 section 6.7
Uppercase processing node
A minimal topology reads String records from src-topic, applies mapValues(value -> value.toUpperCase()), then writes the resulting records to out-topic. The mapValues call creates the processor between the source and sink nodes. section 6.3 section 6.3.1
Use the lower-level Processor API when the DSL does not expose needed control. Build the topology explicitly with addSource, addProcessor, and addSink; supply node names and parent names to wire it. A Processor implements process() for record logic and can use its ProcessorContext to forward records to selected children. section 10.1.1 section 10.1.2 section 10.1.3
Processing nodes become useful for control the DSL may not provide:
- Route a beer sale to domestic or international sinks after converting non-dollar amounts. section 10.1.2
- Delay stock-analysis output until enough samples and calculated conditions justify forwarding. section 10.2
- Maintain sensor aggregations in a state store and emit or clean them according to data-driven conditions and punctuation. section 10.3
Topology descriptions reveal generated node names, parentage, children, sub-topologies, and record-flow direction. Name DSL nodes with Named and configuration nodes with withName so the description communicates each node’s application role rather than only its generated operator name. section 6.6.3
The Processor API trades brevity for control. Prefer the DSL for typical stream processing, mix in a custom process() implementation for an isolated need, and consider a fully explicit Processor API topology for several custom processors or specialized routing. section 10.0 section 10.5
