ну то есть это не вопрос СУБД. 140 гигов или даже там 1 терайбат это не сказать что прям оч много что какой-нибудь постгрес не выдерживает. Индексы в память помещаются? ну и ладненько. Но в целом от разбиения можно выйграть сильно за счет более специализированных моделей данных
ну прикол в том что для репортов микросервисы всегда будут "притормаживать" (если конечно не увеличивать стоимость сильно и вводить какие-то ETL/ELT). Тут ты упираешься в "достать данные". А представь насколько это будет дороже если за данными надо по сети ходить (даже если мы говорим про какие-нибудь фичи типа федерации и т.д,)
самая большая таблица по количеству строк... это таблица с платежками, её можно секционировать или шардировать в принципе, по ней и аналитика должна быть... типа сколько ещё должны заплатить.... за остальные таблички волноваться нет смысла, так как мне видно что больше 80% времени работы субд приходится на эту таблицу
Похоже на типовой биллинг. "Платежка" - это документ, по нему вообще не должно быть никаких расчетов. Документы генерируют операции прихода-расхода с пристыкованными разрезами аналитики, вот по ним все считается
похоже, но тут своя мультивселенная с бизнес процессом... скажем так кто-то боится заплатить лишнее, или заплатить не вовремя, поэтому и расчеты такие есть... и бизнес процесс менять никто не будет, так как там куча нормативки...
к Евгению у меня вопросов нет, я согласен с тем, что он написал. Я не понимаю как у вас в одном сообщение получилось app service, read model, repository дергает по id
обычно, если вы меняете агрегат, то вы знаете его id и соответственно из репозитория берете агрегат по айдишке, если у вас необычный кейс, то попробуйте его описать