An in-memory state store keeps key-value records in application memory, giving fast lookups but losing its local contents when the Kafka Streams application shuts down. Kafka Streams backs the store with a changelog topic, so startup can rebuild the state and resume processing. section 7.4 section 7.4.1
Choose an in-memory store when the performance and storage trade-offs fit the topology:
- Gain faster access because lookups do not retrieve values from disk. section 7.4.6
- Limit capacity to available memory; use Stores.lruMap to evict entries at a configured maximum. section 7.4.6
- Expect restoration from the beginning of the changelog after restart or task movement, while persistent stores may resume faster on a clean restart. section 7.4.1 section 7.4.6
- Name the store through Materialized so its state store and changelog topic remain identifiable and compatible across topology updates. section 7.4.5
Materializing an in-memory poker-score store
KStream<String, Double> pokerScoreStream = builder.stream("poker-game",\n Consumed.with(Serdes.String(), Serdes.Double()));\n\npokerScoreStream\n .groupByKey()\n .reduce(Double::sum,\n Materialized.<String, Double>as(\n Stores.inMemoryKeyValueStore("memory-poker-score-store"))\n .withKeySerde(Serdes.String())\n .withValueSerde(Serdes.Double()))\n .toStream()\n .to("total-scores",\n Produced.with(Serdes.String(), Serdes.Double()));\n\nThe StoreSupplier switches the reduce operation from the default persistent store to an in-memory store; the Serdes define its key and value formats. section 7.4.6
Figure 7.17 As the key-value records get written to the store, they also get written to the changelog topic for data durability.
Follow the record path from the key-value store to its changelog topic to see how in-memory state remains restorable. section 7.4




