Монолит vs микросервисы для системного аналитика

Зачем сравнение спрашивают

«Нам нужно увеличить скорость доставки фич — давайте перейдём на микросервисы». Звучит на каждом втором ретро. Системный аналитик в этом разговоре — тот, кто понимает trade-off и помогает не сделать дорогую ошибку.

Главная боль без понимания темы — стартап-команда из 5 разработчиков делает 15 микросервисов «потому что современно». Через год — операционный ад: deploy в 4 утра, лог-агрегация не работает, никто не знает, кто отвечает за «вон тот сервис». Архитектор увольняется, систему переписывают обратно в монолит.

На SA-собесе обязательный middle+ вопрос: «когда монолит, когда микросервисы?». Ответ «микросервисы лучше» — провал.

Монолит

Монолит — одно приложение с одной кодовой базой, одной БД, одним deploy.

[Frontend] → [Backend (один сервис)] → [Database]

Внутри — модули, слои, классы. Деплой — один артефакт.

Плюсы:

• Простота: один git-репозиторий, один пайплайн
• Транзакции в одной БД (ACID работает)
• Дебаг — один процесс, один лог
• Низкая операционная сложность: один сервис, один deploy
• Быстрый старт: 1 сервис деплоить за день

Минусы при росте:

• Любой деплой = деплой всего приложения
• Один баг → всё лежит
• Скейлинг — целиком (даже если узкое место в одном модуле)
• Команды мешают друг другу в одном репозитории
• Технологии в монолите — одни на всех (один язык, один стек)

Modular monolith — монолит с чёткими модулями и интерфейсами. Промежуточный вариант: сохраняет операционную простоту, но дисциплинирует код. Часто лучший выбор для команд 5–30 человек.

Микросервисы

Микросервис — независимое приложение со своей кодовой базой, своей БД, своим деплоем.

[Frontend] → [API Gateway] → [Service A] → [DB A]
                          → [Service B] → [DB B]
                          → [Service C] → [DB C]

Сервисы общаются по сети (REST/gRPC/Kafka).

Плюсы:

• Команды независимы: свой репозиторий, свой релиз
• Отказоустойчивость: один сервис упал — другие работают
• Скейлинг точечно: только узкие места
• Технологический полиглотизм: где Python, где Java, где Go
• Ясные границы ответственности

Минусы:

• Высокая операционная сложность: 50 сервисов = 50 пайплайнов, 50 мониторингов
• Распределённые транзакции — saga, eventual consistency
• Network latency и failures как часть архитектуры
• Лог-агрегация, distributed tracing, service mesh — обязательны
• Onboarding нового разработчика тяжёлый

Антипаттерн — микросервисы там, где не нужно. Команда из 8 человек × 30 микросервисов = операционный кошмар.

SOA как промежуточный вариант

Service-Oriented Architecture — старший брат микросервисов, ESB-ориентированный (Enterprise Service Bus).

• Сервисы могут быть крупными (sub-system size)
• Часто общая база на нескольких сервисов
• Communication через ESB (центральная шина)

В РФ SOA жив в банках/телекоме/госе. На собесе SA в банке могут спросить про ESB и SOA подробно.

Современная микросервисная архитектура отказывается от ESB в пользу asynchronous messaging (Kafka) и API-композиции в gateway.

Когда что выбирать

Монолит / modular monolith — когда:

• Команда меньше 20–30 человек
• Продукт на ранней стадии (домен ещё не понят)
• Бизнес-логика тесно связана (много транзакций между «модулями»)
• Нет операционной зрелости для микросервисов (нет SRE-команды, нет observability)
• Скорость доставки важнее scaling

Микросервисы — когда:

• Команда 50+ человек, разделены на squads/streams
• Чёткие domain boundaries (DDD-разбиение зрело)
• Нужен independent deployment
• Точечный scaling: один сервис в 100 раз нагруженнее остальных
• Технологический полиглотизм оправдан
• Есть SRE / DevOps для эксплуатации

Эвристика Сэма Ньюмана: «начинайте с монолита, выделяйте микросервисы при чёткой потребности».

Миграция монолит → микросервисы

Strangler pattern — постепенно заменять части монолита микросервисами:

1. Поставить proxy/gateway перед монолитом
2. Выделить bounded context (например, Auth)
3. Создать микросервис auth, перевести на него часть запросов через proxy
4. Постепенно убирать функционал из монолита
5. Повторять для следующих контекстов

Что нужно описать в ТЗ при миграции:

• Sequencing: какой контекст первым (обычно — независимый, низкорисковый)
• Data consistency: как гарантируем consistency между монолитом и новым сервисом
• Rollback plan: как возвращаемся, если новый сервис плох
• Метрики: как поймём, что миграция успешна

«Big bang» миграции — полный rewrite одним релизом — почти всегда провал. Год работы, в момент релиза половина не работает.

Частые ошибки

Микросервисы для маленькой команды. 5 человек на 20 сервисов — операционный коллапс. Modular monolith.

Распределённый монолит. Микросервисы есть, но они tightly coupled: один не работает — всё падает. Хуже, чем монолит, потому что добавлены сетевые проблемы.

Микросервис на каждый CRUD-объект. «UserService», «AddressService», «PhoneService» — это не микросервисы, это distributed обвес. Сервисы вокруг bounded context, не таблиц.

Распределённые транзакции через 2PC. Очень дорого, fragile. Использовать saga и eventual consistency.

Шаринг БД между микросервисами. Антипаттерн: все микросервисы пишут в общую Postgres → coupling. Каждый сервис со своей БД.

Игнорировать observability. Без distributed tracing (Jaeger), centralized logs (ELK), metrics (Prometheus) — отладка в микросервисах невозможна.

ТЗ без описания contracts. В микросервисах API между сервисами — самое важное. Без OpenAPI/proto-файлов команды не могут работать параллельно.

Связанные темы

• CAP теорема на собесе SA
• REST vs SOAP vs gRPC vs GraphQL
• HTTP методы и коды на собесе SA
• Подготовка к собесу системного аналитика
• Сoбеседование системного аналитика

FAQ

Что такое modular monolith?

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

Сколько строк/функционала на один микросервис?

Нет точного правила. Эвристика: «команда из 6–8 человек должна владеть сервисом end-to-end». Если команда не справляется — либо команда мало автономна, либо сервис слишком большой.

Можно ли использовать общую БД в микросервисах?

Не рекомендуется. Coupling возвращается через схему БД. Иногда допустимо для read-only views или legacy-миграции; новые сервисы — со своей БД.

Чем serverless отличается от микросервисов?

Serverless (Lambda) — модель деплоя/billing: функция запускается по событию, платится за вызов. Микросервис — архитектурный паттерн. Можно делать микросервисы на serverless и наоборот.

Какие минимальные требования к команде для микросервисов?

CI/CD, observability (logs/metrics/traces), service registry/discovery, API gateway, культура инженерных стандартов. Без этого микросервисы — это «много распределённых монолитов».

Это официальная информация?

Нет. Статья основана на работах Sam Newman, Martin Fowler, общей практике системной архитектуры.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.