Microservices vs Monolith: что выбрать?

Каждый CTO рано или поздно слышит: "Нам нужны микросервисы, как у Netflix!". Но Netflix — это 10,000 инженеров и миллиарды долларов. А у вас — 5 разработчиков и MVP. Давайте разберемся, когда монолит — это мудрость, а когда микросервисы — необходимость.

Визуальное сравнение

Когда монолит — правильный выбор

• Стартап на ранней стадии: Вам нужна скорость разработки, а не масштаб. Монолит позволяет быстро менять код без оркестрации 20 сервисов.
• Команда < 10 человек: У вас просто нет ресурсов поддерживать инфраструктуру микросервисов (Kubernetes, Service Mesh, Distributed Tracing).
• Низкая нагрузка: Если у вас 1000 RPS, монолит справится на одном сервере. Зачем усложнять?

Когда пора переходить на микросервисы

1. Разные команды, разные темпы: Команда платежей хочет деплоить 5 раз в день, а команда отчетов — раз в неделю. Монолит заставляет всех ждать друг друга.
2. Разная нагрузка на модули: API для мобильного приложения получает 100k RPS, а админка — 10 RPS. В монолите вы масштабируете всё вместе (дорого). В микросервисах — только то, что нужно.
3. Технологическая свобода: Хотите писать ML-модуль на Python, а основной бэкенд на Go? В монолите это боль. В микросервисах — норма.

Золотая середина: Модульный монолит

Начните с монолита, но пишите его как будущие микросервисы. Разделите код на модули с четкими границами (Domain-Driven Design). Когда придет время, вы просто вынесете модуль в отдельный процесс.

Совет NineLab: Микросервисы — это не архитектура. Это организационная структура. Если у вас нет нескольких команд, вам не нужны микросервисы.