Распределенный монолит? Даже удивительно, но значительно чаще, чем каждое второе решение, аудит которого проводим, – распределеный монолит. Сколько индустрия теряет, страшно представить. Это ж как нам не хватает архитектурной экспертизы (в широком смысле). И иногда даже можно не смотреть на as-built, достаточно посмотреть на as-designed, это ведь так очевидно, на той же компонентной, по названиям даже (если исходить из смысла названий): API Service -> Manager Service -> Data Service -> DB Это типичный Layered Monolith: Controller -> Manager -> Service -> Repository -> DB То есть получили издержки на сетевые вызовы, сериализацию, ретраи, дискавери, трассировку, частичные отказы, если не считать координационных издержек, совместимости, распределенного внесения изменений, времени на деплой… и не получили главного преимущества микросервисов - автономности. Хотя называется оно в документах, конечно, «Микросервис UserService», «Микросервис Nginx». Варианта тут всего два: компоненты, которые всегда изменяются вместе, следует либо объединить, либо действительно развязать. Однако, стоит сделать важную оговорку. Названия – это, конечно, хорошо, однако мы ж про инженерию, а в инженерии нельзя просто сказать - должно быть больше или должно быть меньше, в инженерии для каждого распределенного компонента должно существовать экономическое или архитектурное обоснование (все, часть, одно из тех, что ниже, если оно критически важное, могут быть и другие): • Независимое масштабирование • Независимый жизненный цикл • Отдельная команда • Отдельный уровень безопасности • Изоляция отказов • Независимый темп изменения • Отдельная модель данных • Существенная внешняя интеграция И если такого (никакого) обоснования нет, компонент добавляет сложность, но не создает архитектурной ценности.