Today Streams make all state stores to be backed by a changelog topic by default unless users overrides it by disableLogging when creating the state store / materializing the KTable. However there are a few cases where a separate changelog topic would not be required as we can re-use an existing topic for that. A few examples:
There are a few places where the materialized store do not need a separate changelog topic. This issue summarize a specific issue:
1) If a KTable is read directly from a source topic, and is materialized i.e.
In this case table1's changelog topic can just be topic1, and we do not need to create a separate table1-changelog topic.
2) if a KStream is materialized for joins where the streams are directly from a topic, e.g.: