<spanid="streams-developer-guide-topics"></span><h1>Managing Streams Application Topics<aclass="headerlink"href="#managing-streams-application-topics"title="Permalink to this headline"></a></h1>
<p>A Kafka Streams application continuously reads from Kafka topics, processes the read data, and then
writes the processing results back into Kafka topics. The application may also auto-create other Kafka topics in the
Kafka brokers, for example state store changelogs topics. This section describes the differences these topic types and
how to manage the topics and your applications.</p>
<p>Kafka Streams distinguishes between <aclass="reference internal"href="#streams-developer-guide-topics-user"><spanclass="std std-ref">user topics</span></a> and
<spanid="streams-developer-guide-topics-user"></span><h2>User topics<aclass="headerlink"href="#user-topics"title="Permalink to this headline"></a></h2>
<p>User topics exist externally to an application and are read from or written to by the application, including:</p>
<dlclass="docutils">
<dt>Input topics</dt>
<dd>Topics that are specified via source processors in the application’s topology; e.g. via <codeclass="docutils literal"><spanclass="pre">StreamsBuilder#stream()</span></code>, <codeclass="docutils literal"><spanclass="pre">StreamsBuilder#table()</span></code> and <codeclass="docutils literal"><spanclass="pre">Topology#addSource()</span></code>.</dd>
<dt>Output topics</dt>
<dd>Topics that are specified via sink processors in the application’s topology; e.g. via
<codeclass="docutils literal"><spanclass="pre">KStream#to()</span></code>, <codeclass="docutils literal"><spanclass="pre">KTable.to()</span></code> and <codeclass="docutils literal"><spanclass="pre">Topology#addSink()</span></code>.</dd>
</dl>
<p>User topics must be created and manually managed ahead of time (e.g., via the
<aclass="reference internal"href="../../kafka/post-deployment.html#kafka-operations-admin"><spanclass="std std-ref">topic tools</span></a>). If user topics are shared among multiple applications for reading and
writing, the application users must coordinate topic management. If user topics are centrally managed, then application
users then would not need to manage topics themselves but simply obtain access to them.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<p>You should not use the auto-create topic feature on the brokers to create user topics, because:</p>
<ulclass="last simple">
<li>Auto-creation of topics may be disabled in your Kafka cluster.</li>
<li>Auto-creation automatically applies the default topic settings such as the replicaton factor. These default settings might not be what you want for certain output topics (e.g., <codeclass="docutils literal"><spanclass="pre">auto.create.topics.enable=true</span></code> in the <aclass="reference external"href="http://kafka.apache.org/0100/documentation.html#brokerconfigs">Kafka broker configuration</a>).</li>
</ul>
</div>
</div>
<divclass="section"id="internal-topics">
<spanid="streams-developer-guide-topics-internal"></span><h2>Internal topics<aclass="headerlink"href="#internal-topics"title="Permalink to this headline"></a></h2>
<p>Internal topics are used internally by the Kafka Streams application while executing, for example the
changelog topics for state stores. These topics are created by the application and are only used by that stream application.</p>
<p>If security is enabled on the Kafka brokers, you must grant the underlying clients admin permissions so that they can
create internal topics set. For more information, see <aclass="reference internal"href="security.html#streams-developer-guide-security"><spanclass="std std-ref">Streams Security</span></a>.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">The internal topics follow the naming convention <codeclass="docutils literal"><spanclass="pre"><application.id>-<operatorName>-<suffix></span></code>, but this convention
<p>The following settings apply to the default configuration for internal topics:</p>
<ul>
<li>For all internal topics, <codeclass="docutils literal"><spanclass="pre">message.timestamp.type</span></code> is set to <codeclass="docutils literal"><spanclass="pre">CreateTime</span></code>.</li>
<li>For internal repartition topics, the compaction policy is <codeclass="docutils literal"><spanclass="pre">delete</span></code> and the retention time is <codeclass="docutils literal"><spanclass="pre">-1</span></code> (infinite).</li>
<li>For internal changelog topics for key-value stores, the compaction policy is <codeclass="docutils literal"><spanclass="pre">compact</span></code>.</li>
<li>For internal changelog topics for windowed key-value stores, the compaction policy is <codeclass="docutils literal"><spanclass="pre">delete,compact</span></code>. The retention time is set to 24 hours plus your setting for the windowed store.</li>
<li>For internal changelog topics for versioned state stores, the cleanup policy is <codeclass="docutils literal"><spanclass="pre">compact</span></code>, and <codeclass="docutils literal"><spanclass="pre">min.compaction.lag.ms</span></code> is set to 24 hours plus the store's <spanclass="pre">historyRetentionMs</span></code> value.</li>