What does selectKey do, how does it relate to groupBy and the deprecated through(), and what is the modern replacement?

## selectKey `KStream.selectKey((key, value) -> newKey)` returns a new `KStream` whose records have a **new key** and the **unchanged value**. It is stateless. Because it changes the key, it sets the **repartition-required flag** — identical consequence to map/flatMap, but selectKey signals intent clearly ('I'm only changing the key'). Use it when, for example, your records are keyed by event-id but you need to aggregate by customer-id: `selectKey((k,v) -> v.customerId)`. ## selectKey vs groupBy `groupBy(keySelector)` is conceptually `selectKey(keySelector).groupByKey()`. groupByKey alone keeps the existing key (and assumes no upstream rekey requiring repartition); groupBy explicitly re-keys and so always implies a repartition before the aggregation. If your data is already keyed correctly, use `groupByKey()` and avoid the rekey/repartition; only use `groupBy` when you must aggregate on a different key. ## through() — deprecated Historically, `KStream.through("my-topic")` wrote every record to `my-topic` and then immediately re-consumed from it, returning a stream reading from that topic. People used it as a manual repartition step (force records onto a topic whose partitioning matches a new key). Drawbacks: you had to **pre-create and manage** the topic, its partition count, retention, and cleanup yourself, and the round-trip semantics were implicit. ## Modern replacements - **`repartition()`** (Kafka 2.6+): `stream.repartition()` or `stream.repartition(Repartitioned.as("name").withNumberOfPartitions(n).withStreamPartitioner(...).withKeySerde(...).withValueSerde(...))`. Streams creates and **owns** an internal repartition topic — manages its lifecycle, partition count, retention, and naming. This is the direct replacement for through() when you want an internal, Streams-managed repartition. - **`to("topic")` + `builder.stream("topic")`**: when you want a **real, user-visible** topic (e.g. another app consumes it), write it explicitly with to() and re-read it with a new stream. This is the replacement when the topic is part of your contract, not just an internal repartition. ## Putting it together A typical rekey-then-aggregate pipeline: ``` builder.stream("events") .selectKey((k, v) -> v.getCustomerId()) // sets repartition flag .repartition(Repartitioned.as("by-customer")) // optional explicit control .groupByKey() .count(); ``` Without the explicit repartition(), groupByKey() after the selectKey still triggers an auto-named repartition topic. The explicit call just gives you a stable name and control over partitions/serdes.