Можно разделить приложение на сервисы и сохранить общий релиз для каждой обычной правки.

Допустим, каталог и оформление заказа живут в разных контейнерах. Изменение проверки наличия требует правок в обоих, совместной выкладки и парного отката. Границу процесса провели, независимости релизов пока нет.

Перед выделением сервиса стоит назвать ожидаемую пользу: отдельный выпуск версий, масштабирование тяжёлой части или изоляция сбоя. Это разные задачи, и проверять их нужно по-разному.

Если нужна независимая выкладка, возьмите типичную правку. Проверьте в тестовом окружении новую версию сервиса с текущими версиями соседей, включая поведение данных и возможность отката. Одновременный запуск всех последних сборок такой переход не проверяет.

Разовая согласованная миграция допустима. Постоянная необходимость выпускать всё вместе при обычных изменениях указывает, что границы стоит пересмотреть.

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

Мне важно понимать, какую возможность даёт отдельный сервис. Дополнительная сеть без нужной автономии может оставить прежний общий релиз и добавить новые способы получить ошибку.