Как ответить
Основное отличие — в способе развертывания и масштабирования. В монолите всё работает в одном процессе, в микросервисах — каждый сервис — отдельный процесс. Это определяет все остальные различия: как мы деплоим, как отлавливаем ошибки, как масштабируемся под нагрузку.
Монолит проще в разработке на старте. Если команда до 5 человек и продукт не требует высокой доступности, монолит — рабочий вариант. Всё в одном репозитории, одна сборка, один деплой. Но когда кодовая база вырастает до 500 тысяч строк, начинаются проблемы: любое изменение тянет за собой полный редеплой, CI/CD пайплайн тормозит, а баг в одном модуле валит всё приложение. Типичный пример — интернет-магазин, где падение страницы товара ломает и корзину, и оплату.
Микросервисы решают это через изоляцию. Каждый сервис отвечает за свою доменную область: каталог товаров, корзина, платежи — отдельные приложения со своей базой данных и API. Если падает сервис каталога, корзина всё ещё работает, хотя товары не отображаются. Масштабирование тоже точечное: под Black Friday можно накинуть 10 инстансов на сервис заказов, не трогая остальные. Но за это платим сложностью: нужно поднимать service mesh (например, Istio), настраивать circuit breakers, распределённый трейсинг через Jaeger, и синхронизировать данные между сервисами через события или Saga-паттерны.
На практике выбор архитектуры часто упирается в границы контекстов по DDD. Если у вас чётко выделенные bounded context'ы с независимыми данными — микросервисы оправданы. Если бизнес-логика тесно связана (например, в ERP-системе модули "Закупки" и "Склад" постоянно обмениваются данными) — монолит проще поддерживать. Я видел проекты, где микросервисы разбили на 50 штук, а потом потратили год на то, чтобы переписать их обратно в модульный монолит, потому что транзакционная целостность стала адом.
Ключевые метрики для решения: latency между сервисами (если больше 10ms — уже проблема), частота изменений в каждом модуле, и размер команды. Для команды из 10 человек оптимально 3-5 микросервисов, не больше.