Какие признаки указывают на распределённый монолит?

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

Признаки:

• общий релиз — сервисы нельзя выкатить независимо, нужен согласованный порядок;
• общая база — несколько сервисов читают и пишут одни таблицы, схему нельзя менять без согласования;
• синхронные цепочки — пользовательский запрос проходит через пять сервисов, доступности перемножаются, задержки складываются;
• общая библиотека доменных моделей, обновление которой обязательно для всех;
• изменение одной фичи — правки в нескольких репозиториях и командах;
• «болтливые» вызовы — десятки запросов между сервисами на одну операцию.

Признаки здоровой нарезки — наоборот: своя схема данных у сервиса, обратно совместимые контракты, асинхронные события там, где не нужен немедленный ответ, независимые выкатки.

Что делать: найти сценарии с самой сильной связанностью и пересмотреть границы; переносить данные к владельцу; заменять синхронные вызовы событиями и локальными копиями; версионировать контракты; иногда — честно объединить сервисы обратно в один.