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

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

Монолит

Одна кодовая база, одно приложение, одна БД. Всё работает вместе.

Плюсы: простота разработки, отладки, деплоя. Транзакции работают естественно. Один деплой обновляет всё. Команда меньше.

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

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

Десятки маленьких приложений, каждое с своей БД, коммуникация через API.

Плюсы: независимое масштабирование, развёртывание, команды. Технологическое разнообразие (Python для ML, Go для API, Rust для criticalpath). Отказоустойчивость: падение одного сервиса не валит всё.

Минусы: сетевая сложность. Распределённые транзакции — ад. Операционные расходы выше (больше серверов, мониторинг, логгирование). Тестирование сложнее.

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

• Startup до 10 разработчиков — почти всегда монолит
• Средний проект, 10–50 разработчиков — модульный монолит ("moduliths")
• Большая компания, разные команды, разные темпы — микросервисы

Ошибки

Startups копируют Netflix и сразу делают микросервисы. Результат — сложность без выгод. Большие компании годами не могут разделить монолит, и страдают от этого.

Правило

Начинайте с монолита. Переходите на микросервисы когда конкретные ограничения монолита становятся болезненными, а не "потому что модно".