ui call api - >  stream(message bus) -> service -> cache(like redis)  <- scheduler service write to main db

Не так. Немного сложнее. Например, обновление кэша параллельно с БД, чтение последних данных (за последний час, максимум за последние сутки) из кэша, агрегатов, рассчитанных пакетно за предыдущие периоды, месяц, год, десять лет тоже возможно из кэша. Но рассчитываются агрегаты не по данным кэша и даже скорее всего спарком на основе лога сообщений в хадупе. А агрегацию горячих данных можно выполнять с помощью потоковой обработки, с учётом того, что сообщения в очередях могут надёжно храниться довольно долго, часто больше суток

redis поддерживает SQL?

Так, в этой цепочке база по расписанию по данным кэша обновляется?

если не поменяли был форк leveldb, где были подобные запросы (более расширенная работа с timeseries)

Кэш не справляется по апдейтам, только вставка. Возможность считать агрегаты в этом случае необходимость.

Кроме агрегатов ещё и сортировки по разным колонкам которые не доходят до бд

да , с уточнением что сервис "перезаводится" от эвента шины сообщений (stream)

не понимаю) почему не обновлять базу также балками в стриме/ сервисом "повешенным" на топик очереди сообщений, например

вам не кажется, что обновление базы по данным из кэша - это слишком хрупкая конструкция?

Для этого нужен грид или нечто более сложное, чем тот же редис?

Возможно я заблуждаюсь, но как мне кажется, как только мы выносим хоть какую-то логику на уровень базы/кэша и пр., мы что-то делаем не так

Почему так? Потому что чем больше возможностей будет у кэша, задача которого - максимально быстро отдавать данные по ключу или по простейшим запросам, тем больше костылей будет на нём реализовано

А уж про грид и говорить не приходится, архитекторы с фантазией весь банк на него переведут.

Там самодельная шина, не поддерживает такое.  это сейчас в каждой системе есть несколько вариантов "закрытия окон" (привет kafka streams) или батчинг из коробки.  Хрупкая если бы это была финансовая система 😅, ну а так вроде работает и не ломается, держит на 1 сервере много каналов*10-100тысч изменений в секунду.

коллеги, мы тут на днях говорили про уважение бизнеса к крупным вендорам и "отхватывание" инженерами за любые косяки опенсорса.

А кто-то в курсе, предлагать самописные ERP тоже мазохизм с точки зрения принимаемой ответственности?

Хрупкая, потому что, с моей точки зрения, записывать данные сначала в кэш и потом из кэша в базу очень странно. Нужно писать параллельно в кэш и в базу, в базу непосредственно из очереди. Хрупкая, потому что между очередью и базой появляется лишний элемент (кэш), который к тому же может потерять данные

Если у вас гарантирована команда примерно 20-30 человек (зависит от объёма компании, необходимого охвата областей, доменов), и срок до сдачи продукта на 80% года три, то нормально. Если нет, то к черту. Еще должны быть готовы представители, и не рядовые, от каждой области, которые к вам на половину ставки уйдут, на месяца 4ре и более иногда.

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

Очень запутано. Я вижу что в любом случае при распараллеливании появляется "костыль", или приложение пишет и в кеш и в базу, что как то не очень. Мы имеем костыль в приложении. Или появляется промежуточная база/утилита, которая распределяет и в кеш и в базу. Т.е. еще один системный сервис.

Хотя я может что то напутал, сегодня как то "не идет"