Собрались как-то молодые и амбициозные в чате. У того 40 микросервисов, у этого 400, у третьего 4000. Да у нас на планете людей столько нет, чтоб всем этим пользоваться.

По больному...
"Сегодня в завтрашний день не все могут смотреть. Вернее, смотреть могут не только лишь все, мало кто может это делать." (с)

Это не антипаттерн.
Допустим у нас обычная ситуация, был модульный монолит смотрящий в одну бд, возникла необходимость масштабировать, но бд все ещё справляется, это означает что её не трогаем, разбиваем монолит, в итоге у нас стал скажем монолит и N микросервисов и 1 бд.

Известно. Синкать через эвенты. Пока можно решить проблемы на уровне хранения не нужно лезть выше. Но тут уж на что компетенций хватит и денежек)

Или на что мозга хватит - реляционность головного мозга тоже не одним днём выкорчёвывается))

То что вы используете общую базу на несколько микросервисов, и живёте как-то, ещё не означает что это хорошо.

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

Разделенный сетью модуль монолита с общей базой не есть микросервис.

Ну значит он ошибся не с решением, а с тем, что обозвал это микросервисами

Не велика ошибка

Шаринг базы тащемта не хорошо и не плохо. Есть по этому делу даже целые толстые книги

Если все это работает, то вообще нет проблем.
Ошибка в том, что делались какие-то выводы про общую бд и микросервисы на основе того, что не является микросервисом

Да некоторые ещё заменяют шаринг базу на шаринг Кафки (к примеру). И такие и так пойдет я починил. Я вместо базы стал в кафке все данные хранить.
Поменял схему данных на схему сообщений.

Почему вы считаете что разделенный сетью модуль монолита с общей базой не микросервис? Вы имеете ввиду что эти вещи взаимоисключающие или просто недостаточные для заключения?

Ну докинуть всегда можно, но это не всегда работает и не всегда дешевле. Я не могу привести достаточные факты для подтверждения, но думаю в этом чате есть те кто смогут.

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

К тому же, далеко не с первого раза удается верно выделить контексты, и в случае монолита дёшево будет поменять границы. Не вижу пойнта в добавлении сети, и погоне за мифическими "микросервисами" на пустом месте.

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

под модульным монолитом я подразумеваю, что контексты уже выделены

Можно дробить базу и так получить Профит. Мол вдруг есть кусок интенсивно задействованный и его можно вынести. И в целом нет нужды все отпиливать

До тех пор, пока модули ходят в одну бд и общие таблицы, такие себе модули

Вполне, но речь же шла именно про общую базу

Где нет четких границ, и сервисы/whatever запускают грязные руки в общие данные

Разделить базу сложнее и профита больше потому нет смысла сначала заменять вызовы методов на запросы в апишку

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

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

А можно делать нормально и не испытывать необходимости шарить хранилище