Но в кэш тоже надо ведь положить

так мы обновляем кэш по мере прихода новых проводок, в этом и соль data streaming

Ваш кейс больше на redis походит

Смотрите, коллеги, просто моя профдеформация такова, что я до того как  прийти в Java бэкенд, лет 10 занимался ERP системами
и для меня нового ничего в потоковой архитектуре нет
в любой нормальной учётной системе с 80х годов прошлого века есть Ledger, он же append-only лог
и есть таблицы, обновляющиеся по мере добавления зависей в Ledger . Нужно увидеть баланс по счёту? -- быстро берём уже посчитанный

Это очень классный паттерн, его внедрение преобразует целые организации

Но

в случае ERP систем вся эта история живёт в RDBMS

В кафке такого я бы делать не рискнул по целому ряду причин

хотя внешне, с высоты птичьего полёта, всё выглядит также
лог->stream processing->cache

Так Кафка - лог из rdbms. Поэтому они и похоже в такой формулировке. И у оракла есть лог и у постгресс

Лог только удаляется. И Кафка log файлы чистит.

Да, но это --- не ERP-шный Ledger

ERP-шный Ledger хранится вечно, над ним не нависает retention

В ERP-шный Ledger можно добавить новые поля и пересчитать задним числом, т. е. "обогатить" его в процессе развития системы

Наконец, запись в ERP-шный Ledger и в кэш всегда происходит  в одной атомарной транзакции, чего мы не имеем с Kafka+whatever is your cache

Можно хранить весь стэйт в виде лога и при необходимости ( перезагрузок ) его читать , но это может стать очень долгим процессом и система просто не подниматься

Атомарность можно прикрутить средствам Кеша.

Ну да. Вот я, думая обо всём этом, и пришёл к такому выводу.

что если задача, которую вы решаете, допускает перечитывания лишь "хвоста" лога фиксированной длины от "головы",  то это и есть кейс для потоковых систем

а где надо хранить всё от "начала времён" как зеницу ока, там -- пока ещё нет.

прикрутить-то всё можно, вопрос, насколько прочно оно будет держаться 😁

А зачем вам лог тогда . Вы можете в кэше держать стэйт и перечитывать его. Опять же это redis + персистент к нему

Как это зачем лог? А если мы ошиблись в расчётах? А если поменялись требования, и считать надо по-другому? А если мы видим, что сумма некорректная, и нам надо расследование провести, почему она именно такая?

В общем.

Data Streaming -- это очень круто, я уверен, что эта штука потеснит многие существующие решения

Но есть ли у Data Streaming границы применимости? И какие они?

Я попытался сформулировать некоторый критерий, но пока не услышал, чтобы кто-то сказал: "да, я тоже вижу проблему именно так". Видимо, проблему все видят очень по-разному.

Какие решения она потеснит ? Базы данных как есть . Так и будут . И ерп на кафке тоже никто разрабатывать не будет.

как знать, как знать 🤔

Ну ерп точно никто не будет разрабатывать на кафке. Она не для этого. В ней нету ни delete, ни get по ключу. И acid своеобразный. Без этого для ерп никак

Не, опять немного не про то.  Я не говорю о "голой кафке". И ERP тоже не на голом ledger живёт, хоть у него есть ledger, но всё построено вокруг ledger! Имеется в виду архитектура Kafka + Kafka Streams + база данных/кэш. Естествено, голая кафка без get/delete сама по себе мало чего может, это ёжику понятно.

(замените Kafka Streams в предыдущем сообщении на свой любимый фреймворк потоковой обработки)