+

а вот выше которая, плавно перетекшая в обсуждение снапшотов БД и отката миграций.  :)

Так там ничего не было про микросервисы, обсуждали только возможность обеспечить HA и низкий простой для монолита.

Про плюсы и минусы микросервисов даже не начинали говорить )

Mea culpa :)
было бы интересно почитать - впрочем, наверняка, здесь такие уже были. Приеду домой - поищу, в отпуске не очень удобно это делать.

а вот с темы про ORM как-то съехали - без заключительных выводов. Все ждал доберется кто-нить до 1С - ORM оно или не пойми что?

Ну, 1С - это большой DSL, насколько я могу судить. Это уже другой инструмент )

Смотря какой уровень. Для начинающих можно попробовать. Начинался отлично, но через 2 модуля сбежал преподаватель. Сейчас лекционные видео ведут 2 человека, один -  нормально, второй - ужас. И да, начинался примерно с Нового Года, закончится в сентябре, пока ещё не все модули записаны

Ну я уже несколько раз говорил про размер failure domain, graceful degradation и возможность в следующей версии сервиса заменить субд.

Ну, возможность замены СУБД никак не связана с микросервисом или монолитом, она точно такая же для отдельных модулей в монолите, как и для микросервиса.

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

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

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

А деплой, как мы выяснили, для монолита точно такой же, как и для одного сервиса. Ровно с теми же проблемами.
Т.е. если решаем задачу с десятком сервисов - то их деплой в 10 раз сложнее, нежели одного монолита )

Так ведь каждый такой джойн увеличивает техдолг. И что делать с бюджетированием каждой подсистемы по cpu/mem? Чтобы какой-нибудь рассыльщик почты не съел все ресурсы у более важных частей монолита?

Я видел людей, которые логгирование делали в ту же бд, где данные пользователей и история их заказов. Очевидно, что при росте активности пользователей наступает беда. Не обязательно причиной может быть логгирование, но как нам выставить бюджеты по iops/tps для каждой подсистемы, например?

Но почему это техдолг? Оно техдолг только если мы хотим разделять на сервисы, так-то это нормальное решение для монолита или цитадели..

Потому что база может кончится(в плане ресурсов), например.

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

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

Но не во всех проектах кончается база, это вообще нужно изрядно постараться, чтобы база закончилась )

А потом кто-то закоммитит O(n^2) и оно протечёт в прод. А перф-тесты не поймают, потому что тесткейсы не покрыли это.