Из опыта я глубоко убеждён: в большинстве случаев создание новой системы лучше начинать с монолита. Особенно если это абсолютно новый продукт, которому только предстоит выйти на рынок.
При работе с монолитом система эволюционирует. Изначально ваш проект будет не очень большим и сложным, поэтому он будет быстро расти и развиваться. В какой-то момент вы придёте в стадию, где писать проект уже сложно и он не справляется с нагрузкой. Это очень хороший знак, потому что он говорит, что продукт востребован и им пользуются.
В такой ситуации при необходимости можно начать делить монолит на микросервисы: выделять связанные контексты, выносить код и мигрировать базы данных. Это стандартная история IT-мира: у нас был монолит, но мы выросли и мигрировали на микросервисы.
Такой подход позволяет сохранить естественный порядок вещей: сложное вырастает из простого путём эволюции (а порой и революции). Обычно такие системы лучше продуманы и более устойчивы к изменениям, а у компании достаточно денег на техническое и инфраструктурное обеспечение.
Начинать с микросервисов - это гораздо больший риск. Если вы делаете стартап, то у вас вряд ли будет возможность адекватно разделить границы микросервисов. Вам придётся либо постоянно переделывать кучу микросервисов, либо делать распределённый монолит с большим количеством межсервисных взаимодействий и низкой надёжностью. К тому же, для работы в микросервисной среде нужны люди - много людей. Нужно достаточно разработчиков (зачастую - несколько команд), а также нужны квалифицированные DevOps-инженеры.
Зачастую стартапы не могут себе позволить такую роскошь, поэтому попытка делать сразу микросервисы может оказаться губительной для них. Гораздо проще будет начать с монолита и постепенно развиваться.
Даже если вы делаете новую систему в уже существующей компании, то лучше будет начать с монолита. Крайне редко на моём опыте бывали ситуации, когда мы на 100% точно знали, что нужно делать. И уж точно эта определённость не распространялась на весь продукт.
Для грамотного выделения микросервисов нужны ресурсы и знания домена. Без знания домена есть высокая вероятность неудачно выделить сервисы и получить распределённый монолит.
Поэтому если начинаете делать новый продукт - возьмите монолит. Это убережёт вас от кучи проблем в ближайшем будущем.
Но и распиливать монолит нужно вдумчиво: попытка мигрировать слона по кусочкам легко приводит к тому же распределённому монолиту.