Выберешь для проекта микросервисы или монолит

Выбор архитектуры: микросервисы или монолит

Это одно из самых важных решений при разработке backend-системы. Нет универсального ответа — выбор зависит от контекста проекта, команды и требований. Расскажу о критериях и когда выбирать каждый подход.

Монолит: когда выбирать

Преимущества:

• Простота разработки на начальных этапах — всё в одном репозитории
• Производительность — нет сетевых задержек между сервисами
• Проще отладка — единая кодовая база, стек вызовов виден полностью
• Развёртывание — обновляем один артефакт вместо десяти
• Тестирование — интеграционные тесты проще (нет сетевых зависимостей)
• Консистентность данных — транзакции ACID работают из коробки
• Мониторинг — одна метрика, один лог, одна очередь исключений

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

• MVP и стартапы — нужна скорость до первого пользователя
• Маленькая команда (1-3 разработчика) — невозможно параллельно разрабатывать микросервисы
• Простая предметная область — нет сложных зависимостей между доменами
• Сильные требования к консистентности — например, финтех
• Средний объём трафика — не требуется независимое масштабирование компонентов

Микросервисы: когда выбирать

Преимущества:

• Независимое масштабирование — можно масштабировать только платежный сервис
• Независимое развёртывание — команда A развёртывает без влияния на команду B
• Полиглотизм — разные сервисы на разных стеках (Python для ML, Go для высоконагруженности)
• Отказоустойчивость — сбой одного сервиса не роняет всю систему
• Автономность команд — каждая команда владеет своим сервисом полностью

Недостатки:

• Сложность — распределённые системы — это экспоненциально сложнее
• Сетевые задержки — каждый вызов это сеть, может быть 100ms вместо 1ms
• Отладка — найти баг в цепочке из 5 сервисов сложнее
• Консистентность — нет ACID транзакций, нужна eventual consistency
• Мониторинг — нужна трассировка (distributed tracing) для понимания потоков
• Операции — нужно управлять десятками контейнеров, K8s усложняет

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

• Большая команда (10+ разработчиков) — иначе команды мешают друг другу
• Высокие требования к масштабируемости — разные части нагружаются по-разному
• Независимые домены — есть чёткие границы между бизнес-доменами (платежи, уведомления, пользователи)
• Требуется полиглотизм — разные языки для разных задач
• Высокие требования к надёжности — критично, чтобы сбой одной части не сломал всё

Реальные примеры

Amazon — начала с монолита, разбила на микросервисы когда команда выросла и трафик стал огромным.

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

Stripe — остаётся монолитом, но с очень хорошей внутренней архитектурой. Это работает, потому что:

• Доменная граница между платежами и расширениями не требует развёртывания в разный момент
• Монолит позволяет им совершенствовать консистентность платежей

Моя рекомендация

Начните с монолита:

1. Смешайте все домены в одном приложении
2. Используйте хорошую архитектуру (слои, разделение ответственности)
3. Убедитесь, что рост трафика не требует независимого масштабирования

Мигрируйте на микросервисы только когда:

• Монолит начинает тормозить и не масштабируется
• Команда выросла настолько, что разработчики мешают друг другу
• Есть явные независимые домены (платежи, логирование, аналитика)
• Команда готова к operational complexity микросервисов

Гибридный подход (рекомендуется):

• Ядро в монолите (пользователи, основной бизнес-логика)
• Тяжёлые операции в микросервисах (видеообработка, ML, аналитика)
• Message queue между ними (RabbitMQ, Kafka)

Это даёт преимущества обоих миров: простота разработки ядра и масштабируемость для специализированных компонентов.