Микросервисы vs монолит: когда что выбирать — полный разбор

12 июля 2026 г.от txtly

«Монолит — это legacy. Микросервисы — это modern». Если вы слышите такой аргумент при выборе архитектуры — бегите. Выбор между монолитом и микросервисами не про «старое vs новое». Это инженерное решение с конкретными критериями, компромиссами и ценой ошибки.

Не догма, а спектр

Прежде всего: это не бинарный выбор. Реальные системы находятся в спектре:

Монолит → Модульный монолит → Сервис-ориентированная → Микросервисы → Наносервисы

Тип	Суть	Пример
Монолит	Одна кодовая база, один деплой, одна БД	Shopify (на старте)
Модульный монолит	Одна кодовая база, но строгие границы модулей. Можно выделить сервис позже	Shopify (сейчас)
SOA	Несколько сервисов, общая шина данных	Enterprise-системы
Микросервисы	Много независимых сервисов, свои БД, свой деплой	Netflix, Uber
Наносервисы	Функция = сервис. Почти всегда перебор	Эксперименты Amazon Lambda

Большинству проектов нужен модульный монолит. Микросервисы — для очень специфических условий.

Критерии выбора

1. Размер команды — главный критерий

Команда	Рекомендация
1–5 разработчиков	Монолит. Микросервисы съедят всё время на инфраструктуру
5–20 (2–3 команды)	Модульный монолит. Сервисы выделять точечно по мере роста
20–50 (4–8 команд)	Начало микросервисов. Выделять по границам команд
50+	Микросервисы оправданы

Правило Конвея: архитектура системы отражает структуру коммуникаций организации. Если у вас 2 команды и 20 микросервисов — вы нарушили правило Конвея и будете страдать.

2. Сложность домена

Домен	Рекомендация
Простой, понятный, стабильный	Монолит. Микросервисы добавят сложности без пользы
Сложный, с разными скорингами в разных модулях	Модульный монолит с перспективой выделения
Сложный, разные команды владеют разными частями	Микросервисы по границам доменов (Domain-Driven Design)

Если вы не можете провести границы bounded context'ов — вам рано в микросервисы. Непонимание границ → размазанная логика между сервисами → распределённый монолит. Это худшее из обоих миров: сложность микросервисов + связанность монолита.

3. Масштабирование

Микросервисы нужны, если:

Разные части системы требуют radically разного масштабирования (поиск — 10 000 RPS, админка — 10 RPS)
Разные части требуют разных технологических стеков (поиск на Go, отчёты на Python, API на Java)

Монолит достаточен, если:

Вся система масштабируется одинаково
Можно масштабировать монолит горизонтально (несколько экземпляров за балансировщиком)

Netflix перешёл на микросервисы не потому что «это модно», а потому что их монолит не справлялся с сотнями миллионов пользователей.

4. Скорость разработки и частота деплоя

Ситуация	Выбор
Нужно быстро выкатить MVP, проверить гипотезу	Монолит
Релизы каждые 3–6 месяцев	Монолит
10 команд деплоят независимо, несколько раз в день	Микросервисы
Одна команда деплоит раз в неделю	Модульный монолит

Парадокс скорости: на старте монолит радикально быстрее. Один репозиторий, один деплой, одна БД. Микросервисы на старте замедляют всё: CI/CD, тестирование, отладку, мониторинг. Их преимущество раскрывается только при ≥4 командах.

5. Требования к надёжности

Микросервисы помогают, если:

Отказ одного модуля не должен ронять всю систему (изоляция отказов)
Разные модули имеют разные SLA (платежи — 99.99%, рекомендации — 99%)

Монолит достаточен, если:

Отказ любого компонента = отказ всей системы — и это приемлемо (не финтех)

Чек-лист принятия решения

Перед выбором архитектуры — ответьте на вопросы. Если больше ответов в правой колонке — микросервисы. Если в левой — монолит.

Вопрос	Монолит	Микросервисы
Сколько команд?	1–3	4+
Как часто деплои?	Раз в неделю	Несколько раз в день
Разные команды владеют разными модулями?	Нет, одна команда на всё	Да, чёткое разделение
Нужно независимое масштабирование частей?	Нет, система однородна	Да, нагрузка неравномерна
Нужен разный техстек для частей?	Нет, один язык/фреймворк	Да, разные задачи требуют разного
Изоляция отказов критична?	Нет, система простаивает целиком или работает	Да, части могут отказывать независимо
Есть опыт распределённых систем?	Нет	Есть
Стадия продукта?	MVP / ранний рост	Масштабирование

Что делать, если вы уже в монолите и «пора» в микросервисы

Не «переписываем всё на микросервисы». Это убило больше проектов, чем любой баг.

Стратегия душителя (Strangler Fig):

Выделите один bounded context — один модуль с чёткими границами
Вынесите его в отдельный сервис, сохраняя всё остальное в монолите
Наблюдайте 2–3 месяца: стало лучше? Какие неожиданные проблемы?
Если ок — выделяйте следующий модуль. Если нет — верните обратно

Первый выделенный сервис — самый дорогой. Вы платите за инфраструктуру: service discovery, мониторинг, трейсинг, CI/CD. Каждый следующий — дешевле.

Распределённый монолит — главная опасность. Симптомы:

Изменение в сервисе A требует изменения в сервисе B
Сервисы деплоятся синхронно, всегда вместе
Сервисы используют одну БД
Отказ сервиса A роняет сервис B

Если вы видите эти симптомы — вы построили распределённый монолит. Варианта два: вернуться в монолит или перепроектировать границы сервисов.

Итог: начинайте с монолита

«Almost all the successful microservice stories have started with a monolith that got too big and was broken up» — Martin Fowler

Правильный путь: монолит → модульный монолит → выделение сервисов по мере роста команд. Не наоборот.

Микросервисы — решение проблем масштаба, а не проблем дизайна. Они не исправляют плохую архитектуру — они делают её распределённой и в 10 раз более дорогой в поддержке.

Связанные статьи на сайте

Что дальше

Кеширование: паттерны, стратегии, реализации — как кеширование работает в монолите и микросервисах: распределённый кеш, инвалидация, Redis
System Design: как проектировать масштабируемые системы — фреймворк проектирования и компромиссы монолит/микросервисы

Связанные статьи: Архитектурные паттерны ИТ-систем: справочник 80+ концепций, 97 принципов архитектора ПО, Архитектурные роли в ИТ: кто какую архитектуру выбирает

Архитектура и инженерия ПО Языки программирования

архитектура разработка микросервисы монолит принципы стратегия

Монолит или микросервисы? Спектр архитектурных решений: от Big Ball of Mud до модульного монолитаАрхитектура — не бинарный выбор между монолитом и микросервисами. Спектр: слоёный монолит, модульный монолит, coarse SOA, микросервисы. Monolith First, архитектурные кванты, когда оставаться на монолите. Mermaid-диаграммы и книга рекомендаций.
Event-Driven Architecture: когда события управляют системойEvent-Driven Architecture: события, event sourcing, CQRS, брокеры сообщений (Kafka, RabbitMQ). Когда EDA оправдана, а когда добавляет сложности без пользы.
ADR (Architecture Decision Records): как документировать архитектурные решения — шаблоны, примерыADR — как документировать архитектурные решения: шаблон Nygard, MADR и Y-Statement, пример заполнения и реальные кейсы из open source. ADR журнал и реестр решений, инструменты adr-tools. Когда писать ADR, а когда не стоит.
C4 Model: документируем архитектуру за 4 шага с примерами и MermaidЧто такое C4 Model и как документировать архитектуру ПО на 4 уровнях: Context, Container, Component, Code. Практические примеры с Mermaid-диаграммами для каждого уровня. C4 vs UML: когда что использовать.
Кеширование: паттерны, стратегии и реализацииПолный инженерный гайд по кешированию — паттерны (Cache-Aside, Read-Through, Write-Behind), стратегии инвалидации, Redis, HTTP-кеширование. Как быстро подключить кеш в Python, Go, на уровне архитектуры.