Спасибо что спросил :) В общих словах это что-то типа

event sourcing (read model) - KStream (S1) -> groupByKey -> aggregate -> join back with S1, на выходе пишу в отдельный топик новые эвенты на основе накопленных данных.

По бизнес флоу получается что у меня есть много короткоживущих сущностей (около минуты) и очень мало долгоживущих (около часа).
В итоге получается где-то 100-200 новых сущностей в минуту. У всех обязательно есть конечный эвент после которого по этом ключу больше не будет новых эвентов.
Накопленное состояние чищу через tombstone, пока сущность жива меня интересует только последнее накопленное состояние.

Главный вопрос - хочу настроить адекватный компакшен для этого сценария (чтоб кафка брокер не насиловать, и чтоб было приемлемое время восстановления kafka streams приложения в худшем случае когда есть потеря локальных файлов RocksDB), что-то подсказывает что мне нужно рассчитать возможный размер состояния одной сущности, перемножить и прикинуть segment.bytes, segment.ms, min.cleanable.dirty.ratio.

Бонусный вопрос (сам еще не исследовал) - я заметил что в changelog topic пишутся сообщения с одним и тем же состоянием (т.к. некоторые исходные эвенты я просто не использую в агрегации), есть ли какой-то способ фильтр сделать или типа flatMap версию для aggregate, чтоб не писать лишнее в changelog topic?
Как это часто бывает пока писал бонусный вопрос - примерно понял как это можно сделать перед тем как запускать агрегацию, но кода будет явно больше чем если б я мог куда-то воткнуть условие по которому бы определялось надо ли писать сообщение в ченжлог топик или нет

Погляди как тут написано - вроде похоже на твою задачу и не требует особого тюнинга брокера https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Stream+Usage+Patterns#KafkaStreamUsagePatterns-Howtomanagethesizeofstatestoresusingtombstones?