Монолит и микросервисы: в чём разница простыми словами

Вячеслав Степанов — проджект-менеджер, ментор · 28 октября 2026

Проджект-менеджер оценивает кнопку «Напомнить» в один день работы, а разработчики называют пять. Спор возникает из-за того, что проджект видит кнопку в интерфейсе, а команда видит всё, что за ней стоит. Чтобы говорить с разработчиками на одном языке, не нужно уметь программировать. Достаточно понимать, как устроено приложение и чем монолит отличается от микросервисов.

Если видео не открывается, смотри на YouTube (может понадобиться VPN).

Как устроено веб-приложение

Любое приложение в интернете работает по схеме «клиент и сервер». Клиент открыт у пользователя: браузер, мобильное приложение, Telegram-бот. Сервер стоит в дата-центре и выполняет работу. Они общаются через запросы и ответы по протоколу HTTP, подробнее об этом в статье про API.

Внутри приложение обычно делят на три слоя:

• Интерфейс (фронтенд) показывает пользователю страницы, кнопки и формы.
• Логика (бэкенд) считает и решает: проверяет пароль, распределяет оплаты, отправляет уведомления.
• Данные (база данных) хранят пользователей, уроки, платежи и всё остальное.

Рядом часто работают два помощника. Кэш хранит в быстрой памяти то, что запрашивают часто: из кэша данные приходят за миллисекунду, а из базы за десятки миллисекунд. Очередь задач уводит долгую работу в фон: пользователь нажал «отправить всем письмо», сразу получил ответ «приняли», а письма уходят чуть позже.

Собрать эти слои в работающий продукт можно двумя основными способами.

Что такое монолит

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

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

Что такое микросервисы

Микросервисы — подход, при котором приложение делят на несколько небольших сервисов. Каждый отвечает за свою область продукта, у каждого свой код и свой выпуск, а между собой они общаются запросами или через очереди сообщений. Термин стал широко известен после статьи Джеймса Льюиса и Мартина Фаулера «Microservices» в 2014 году.

Кроме изоляции сбоев микросервисы дают свободу: сервис уведомлений можно обновлять хоть каждый час, не трогая оплаты, а разные сервисы можно писать на разных технологиях. Платить за это приходится сложностью. Чем больше отдельных частей, тем больше мест, где что-то сломается. Нужно следить за множеством сервисов, собирать их логи в одно место и прослеживать запрос, который прошёл через пять систем. Для этого нужны отдельные инструменты, например Kubernetes, и опытные DevOps-инженеры.

Сравнение в одной таблице

Что выбирают и почему

Мартин Фаулер в 2015 году сформулировал совет «сначала монолит»: успешные системы на микросервисах чаще всего вырастали из монолита, который стал слишком большим. Начинать сразу с микросервисов рискованно, потому что на старте границы между частями продукта ещё непонятны.

Обратные переходы тоже бывают. В 2023 году команда Prime Video рассказала, как перевела один из своих сервисов мониторинга с распределённой архитектуры на монолит и сократила расходы на инфраструктуру на 90%. Netflix, наоборот, после крупного сбоя базы данных в 2008 году начал переезд в облако и на микросервисы и завершил его к 2016 году.

Между двумя крайностями есть модульный монолит: одно приложение, но с чёткими внутренними границами между модулями. Его часто выбирают небольшие продукты, которые хотят оставить себе дорогу к микросервисам.

Есть ещё закон Конвея. Программист Мелвин Конвей в 1968 году заметил, что системы повторяют структуру общения в организации, которая их создаёт. Если в компании пять независимых команд, их продукт естественно делится на пять частей. Поэтому, выбирая архитектуру, компания заодно решает, как будут устроены команды.

Зачем архитектура проджект-менеджеру

На примере видно, откуда берутся «пять дней вместо одного»: нужен новый компонент во фронтенде, новый метод на бэкенде, новая таблица в базе, фоновая задача на отправку и интеграции с ботом и почтой. В каждом месте нужны проверки, и в каждом что-то может сломаться. Проджект, который видит эту цепочку, оценивает фичу по количеству задетых частей системы.

• Понимая архитектуру, проджект задаёт точные вопросы для оценки и рисков: какие сервисы задеты, нужна ли миграция базы, кто тестирует интеграцию.
• Фичу в микросервисах часто делают несколько команд. Проджект согласует порядок работ и сроки между ними, чтобы одна команда не ждала другую.
• В монолите выпуск общий для всех задач, а в микросервисах сервисы выпускают по отдельности, и их новые версии должны быть совместимы друг с другом.
• Когда что-то упало, проджект понимает, какой сервис виноват, кого звать и что продолжает работать.

Вопрос на собеседовании

Проджектов часто спрашивают: «Микросервисы всегда лучше монолита?». Сильный ответ показывает, что ты понимаешь компромисс. Примерно так: «Нет, это вопрос задачи. Монолит проще и дешевле, особенно для нового продукта и небольшой команды. Микросервисы оправданы, когда несколько команд должны работать независимо, у продукта есть отдельные области или разным частям нужны разные технологии. Без таких причин они добавляют сложность и расходы».

Типичные ошибки

• Фичу оценивают по интерфейсу: кнопка выглядит простой, а за ней пять частей системы. Спроси техлида, какие слои и сервисы она задевает.
• Микросервисы считают признаком зрелости. Модное слово не делает продукт лучше: архитектуру выбирают под масштаб и команды.
• Про инфраструктуру забывают. Переход на микросервисы требует мониторинга, сбора логов и людей, которые это поддерживают. На это уходят время и деньги, их закладывают в план.
• Выпуски не согласуют: один сервис обновили, другой ещё ждёт новых данных, и интеграция ломается. Порядок выпусков проговаривают заранее.
• Проджект решает технические вопросы за команду, хотя выбор архитектуры принадлежит техлиду и разработчикам. Проджект приносит в разговор сроки, риски и ограничения бизнеса.

Частые вопросы