Выбирая микросервисы, вы выбираете не только архитектуру. Вы нанимаете распределенные транзакции, наблюдаемость, отдельные релизы и новые границы ответственности. Команда готова оплачивать этот счет?

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

Вместе с сервисами команда получает другую операционную модель:

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

Microsoft Architecture Center формулирует это прямо: отдельные сервисы проще, но система в целом получает больше движущихся частей. Martin Fowler описывает ту же развилку как "microservice premium" — дополнительную цену распределенности и эксплуатации.

Поэтому вопрос "монолит или микросервисы?" я бы заменил тремя другими:

1. Какие изменения действительно должны выпускаться и масштабироваться независимо?

2. Где уже понятны устойчивые бизнес-границы, а где мы пока только изучаем домен?

3. Есть ли у команды платформенные возможности: CI/CD, трассировка, метрики, управление схемами и инцидентами?

Если ответы пока размыты, модульный монолит — не архитектурное поражение. Это способ сохранить короткий цикл обратной связи и сначала доказать границы внутри кода. Выделять сервис стоит не "на будущее", а когда конкретная граница мешает скорости, надежности или независимости команды.

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

По какому сигналу ваша команда понимает, что модуль уже пора выделять в отдельный сервис?

#backend #architecture #microservices #platformengineering #teamlead #izagprog