Монолит vs микро

Монолит — одно приложение, где вся логика (заказы, пользователи, платежи) живёт в одном кодовом проекте и деплоится целиком. Микросервисы — то же самое разбито на независимые сервисы, каждый со своей базой и деплоится отдельно.

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

Users своя БД Orders своя БД Payments своя БД

Копнуть глубже

Монолит выигрывает на старте проекта:

проще разрабатывать (один проект, один деплой);
нет сетевых задержек между модулями (обычный вызов метода вместо HTTP);
проще обеспечить целостность данных (одна транзакция на всё, см. тему «Транзакции, ACID, уровни изоляции»).

Микросервисы выигрывают на масштабе:

разные команды могут разрабатывать и деплоить независимо, не блокируя друг друга;
можно масштабировать только тот сервис, который реально нагружен (например, только Orders под Чёрную пятницу), а не всё приложение целиком;
падение одного сервиса (при правильной защите — см. тему «Circuit Breaker») не обязательно роняет всю систему.

Цена микросервисов — сложность. Сетевые вызовы между сервисами ненадёжны (см. тему «Зачем очереди»), данные распределены по разным базам (нет единой транзакции на всё, нужны компенсирующие механизмы — см. тему «Saga»), нужна инфраструктура для service discovery, мониторинга, трассировки запросов через несколько сервисов.

Главное правило: не начинай с микросервисов. Большинство успешных систем стартовали как монолит и переходили к микросервисам только когда монолит реально стал мешать расти команде и системе — это решение по необходимости, а не “потому что модно”.

🎤 Закрыл тему, если можешь объяснить:

• разницу монолита и микросервисов в структуре;
• ключевые плюсы и минусы каждого подхода и почему не стоит начинать с микросервисов (если дошёл до 2-го слоя).