Какие плюсы и минусы перехода от монолита к микросервисам и обратно?
Что проверяют
Понимаете ли вы, что это компромисс, и знаете ли, что обратный переход бывает осознанным решением, а не поражением.
Как отвечать
Плюсы разделения: независимая выкладка команд, изоляция отказов, точечное масштабирование узких мест, свобода в выборе технологий, понятные границы владения кодом.
Минусы: сеть ненадёжна, и каждый вызов может не дойти или прийти дважды; распределённой транзакции нет, вместо неё саги с компенсациями и согласованность в конечном счёте; отладка требует сквозной трассировки; данные размазаны, и соединение таблиц заменяется вызовами; инфраструктуры, наблюдаемости и людей нужно заметно больше.
Ключевая мысль: микросервисы решают организационную проблему, а не техническую. Их берут, когда несколько команд мешают друг другу выкатываться. Если команда одна, вы платите за координацию, ничего не получая взамен.
Обратный переход это нормальная практика, и её стоит назвать. Amazon Prime Video и Segment публично возвращались к монолиту: накладные расходы на сеть и сериализацию оказались дороже выигрыша. Обратно проще, чем вперёд: слияние сервисов с общей базой убирает саги и сквозную трассировку. Сложность в другом, в том, чтобы не потерять уже сложившиеся границы модулей.
Здравый средний путь это модульный монолит: чёткие границы модулей внутри одного развёртывания, и выделение сервиса только там, где для этого есть настоящая причина.
Где спотыкаются
Считают микросервисы по умолчанию более зрелой архитектурой.
Не называют ни одной сложности, кроме сложности развёртывания.
Забывают про согласованность данных, а это главная боль.
Считают возврат к монолиту признаком неудачи.