title: Why enable Record Caches In Kafka Streams Processor API if RocksDB is buffered in memory?
body: <p>I am trying to understand RocksDB behavior in Kafka streams processor API. I am configuring a persistent StateStore using the default RocksDB that KStreams provide. </p>
  
  <pre><code>StoreBuilder countStoreBuilder =
    Stores.keyValueStoreBuilder(
      Stores.persistentKeyValueStore("Counts"),
      Serdes.String(),
      Serdes.Long())
  </code></pre>
  
  <p>I am not doing any aggregation, join, or windowing. I am just receiving records and comparing some of them to previous items in the store and storing some of the records I receive in the state store.</p>
  
  <p>The developer guide mentions that you can enable record caches in the Processor API by calling <code>.withCachingEnabled()</code> on the above builder. </p>
  
  <blockquote>
    <p>The cache "serves as a read cache to speed up reading data from a state store" - <a href="https://docs.confluent.io/current/streams/architecture.html#record-caches" rel="noreferrer">Record Caches Kafka Streams</a></p>
  </blockquote>
  
  <p>However, my understanding is that RocksDB in persistent mode is first buffered in memory and will expand into disk only if the state doesn't fit in RAM.</p>
  
  <blockquote>
    <p>RocksDB is just used as an internal lookup table (that is able to flush to disk if the state does not fit into memory
    RocksDB flushing is only required because state could be larger than available main-memory. <a href="https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Streams+Internal+Data+Management" rel="noreferrer">Kafka Streams Internal Data Management</a></p>
  </blockquote>
  
  <p>So how does record caches speed up the read from the state store if both are buffered in memory? It seems to me that record caches overlap with RocksDB behavior.</p>