Я только наверное тебя не так понял.

Насчет транзакции в Stream, вопрос выглядит странным, но задача типичная (мне кажется).
Хранилище уже есть.

1. Есть сервис который получает сообщения по Кафке и сохраняет в медленное хранилище;
2. Из-за того что хранилище медленное, в Кафке может быть лог необрадотаных сообщений;
3. Клиент может запрашивать сообщения у сервиса и может быть 3 варианта:
   3.1 Сообщение в медленном хранилище - работает;
   3.2 Сообщение еще в Кафке;
   3.3 Сообщения с таким ключом не поступало;
Нужно различать последние три сосотояния и нужный ответ.

Можно конечно поставить Redis/EVCache/итд. впереди и сохранять и/или в него.
Но это дополнительный компонент, а Кафка уже есть.

Если в Streams нет транзакции, то я могу просто добавить пару retry-ов чтобы подождать (вдруг через секунду сообщение появится).
Но хотел узнать, может есть идеи получше.

P.S. В KTable я планировал хранить 30 минут последних сообщений.

для 3.2 я бы тоже выбрал ktable. одно непонятно - причем здесь транзакции ? какое они имееют отношение к slow storage ?

народ для тестовых стендов лучше делать 1 кафку на множество стендов в кубере, или на каждый проект свою кафку лучше?

Я бы делал тестовую - отдельно на проект

Чтоб потом не мучаться с удалением левых топиков и пр

Настраиваю ssl для Кафки. Передаю ssl.keystore.password в кавычках. Кафка требует без ! Можно ли скормить в кавычках . Пример : "12345" , а она требует просто 12345

а где передаешь. в конфиге кафки? или в докере как переменную?

В конфиге

У меня просто конфигурации генерируя средством установки. Он оборачивает в кавычки пароли т.к в других частях системы всюду в кавычках

Или можно в это значение не пароль прописать , а ссылку на файл, где это пароль лежит ?

можно поменять это поведение. не вижу проблемы

скорее нет, чем да

Если в KTable нет записи, я хочу быть уверен что и в исходном топике сообщения нет. Без всяких eventual consistency.

мне кажется, это некорректная постановка. можно говорить о том, что ключ появится в определенном интервале времени. и store здесь работает

> Без всяких eventual consistency.
это утопия, по крайней мере в случае с кафкой 8-)

не очень понял исходную задачу
внезапно очевидно решение ( в отвязке от кафка стримов, хоть руками пиши) - сообщение пишется в топик, когда-нибудь оно прочтется в стор. Полагаться что оно там есть - нельзя. Делать так, чтобы сначала писать в базу, потом в кафку - можно, сложно. привет транзакции между базой/кешом/etc.

если нужно работать после обработки конкретного сообщения - ну привет causal consistency

Спасибо. Понял что транзакционности нет. Хранить последние сообщения в KTable муторно, чистить надо, ttl нет. Наверное сделаю кеш руками - второй консьюмер который складывает сообщения быстро в память. А медленный консьюмер пусть себе медленно пишет в хранилище.

можно, а какой объем данных предполагается в кеше ? и такой поход не гарантирует что кешовый лисенер будет всегда consistent с топиком (залипнет на ребалансе, например). надо быть готовым к кейсам когда в топике есть, в хранилище - тоже уже есть, а в кеше - еще нет.