1 кейс.
У вас есть запросы на которые нужно отвечать быстро (текущее состояние) и какой-то сервис с отчетами. Когда пользователи запрашивают большой отчет скорость ответа текущего состояния начинает проседать. Тогда вы делаете отдельный сервис для отчетов, выносите его в отдельное приложение и на отдельную виртуалку. Таким образом вы изолируете потребляемые ресурсы и устраняете влияние сервисов друг на друга. Плюс получаете возможность отдельно масштабировать сервис отчетов во времена наибольшей нагрузки.
2 кейс.
У вас есть сервис авторизации для которого нужно учесть множество разных требований и стандартов по безопасности. Вы привлекаете отдельную команду для его разработки с определенными навыками. В этом случае вы изолируете ресурс "навыки разработки безопасных сервисов" чтобы команда не тратила свое время на другие фичи.
3 кейс.
Вы делаете несколько сложных сервисов и решаете распаралелить разработку на несколько команд. Одна команда делает "Кинопоиск", другая "Афишу". Все они обращаются к серверу авторизации из кейса 2 и бекендам из кейса 1.
Итог.
Разделение на несколько приложений - это либо логическое разделение, когда приложения делают разные и несвязанные вещи. В этом случае удобно думать о разных задачах как о разных приложениях. Отдельно их разрабатывать, деплоить и т.д.
Либо это управление вычислительными мощностями. Когда разные части системы требуют разделения ресурсов, нелинейного масштабирования или имеют совсем разный режим работы (например АПИ для загрузки фоток и асинхронный воркер который делает превьюшки для этих фоток)
Либо это управление на уровне человеческих ресурсов, когда приходится вводить в разработку несколько команд.
