Кто принимал решение между выбором монолита и микросервиса?

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

Вопрос о выборе архитектуры — это часто задаваемый вопрос на собеседованиях, потому что он показывает твоё понимание trade-offs и способность участвовать в архитектурных решениях. Давайте разберём обе стороны.

Обычный процесс принятия решения

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

1. Техническое руководство (Tech Lead / Engineering Manager)

• Анализирует требования проекта
• Оценивает текущие ресурсы команды
• Оценивает scalability requirements

2. Архитектор (если есть)

• Проектирует систему
• Предлагает несколько вариантов
• Анализирует trade-offs

3. Команда разработчиков

• Обсуждает практические проблемы
• Задаёт вопросы по operational complexity
• Высказывает мнение по внедрению

4. Бизнес / Продакшен

• Определяет timeline
• Ставит бюджетные ограничения
• Указывает приоритеты

Когда выбирают монолит

Пример: Монолитная архитектура лучше на ранних стадиях

Стартап (месяцы 1-12):
├─ Быстрое прототипирование
├─ Маленькая команда (2-5 человек)
├─ Одна база данных
├─ Простая развертка (один сервер)
└─ Фокус на product-market fit

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

• Простоте в разработке — всё в одном месте
• Простоте в развертке — один Docker контейнер
• Простоте в отладке — shared memory, single codebase
• Простоте в транзакциях — ACID транзакции в одной БД
• Меньше сетевых задержек — функции вызываются напрямую

Недостатки:

• Масштабирование — приходится масштабировать весь монолит
• Развертывание — даже маленькое изменение требует переразвёртывания всего
• Технологический стек — все компоненты используют один язык/фреймворк
• Отказоустойчивость — одна ошибка может упасть весь сервис

Когда выбирают микросервисы

Пример: Микросервисная архитектура для grown-up компаний

Зрелая компания (годы 2+):
├─ Разные команды работают параллельно
├─ Разные требования к scalability
├─ Разные требования к SLA
├─ Несколько БД
├─ Distributed deployment
└─ Фокус на операционной эффективности

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

• Независимое масштабирование — масштабируешь только нужный сервис
• Независимое развертывание — не нужно переразвёртывать весь сервис
• Технологическая гибкость — разные сервисы могут использовать разные технологии
• Организационное соответствие — разные команды владеют разными сервисами (Conways Law)
• Отказоустойчивость — падение одного микросервиса не ломает всю систему

Недостатки:

• Операционная сложность — нужна хорошая инфра (Kubernetes, логирование, мониторинг)
• Сетевая задержка — коммуникация между сервисами через сеть
• Консистентность данных — distributed transactions сложнее ACID
• Deployment complexity — больше точек отказа при развертывании
• Стоимость — больше серверов, больше инструментов

Реальный сценарий из опыта

Пример: Решение которое я наблюдал / принимал участие

Стартап E-commerce (500K DAU):

ЭТАП 1 (месяцы 1-6): Монолит на Node.js
├─ Бэкенд в Express.js (все API в одном сервисе)
├─ PostgreSQL (одна БД)
├─ Redis (кэш и сессии)
└─ Результат: быстрое развитие, MVP за 3 месяца

ЭТАП 2 (месяцы 7-12): Начало масштабирования
├─ Проблемы:
│  ├─ Обработка платежей блокирует основной поток
│  ├─ Email рассылки замораживают сервис
│  └─ Поиск товаров требует отдельного масштабирования
├─ Решение: Отделили критические сервисы
│  ├─ Payment Service (отдельно, может падать независимо)
│  ├─ Email Service (асинхронно через очередь)
│  └─ Search Service (ElasticSearch + отдельный сервис)
└─ Архитектура: Модульный монолит + 2-3 микросервиса

ЭТАП 3 (год 2+): Full микросервисы
├─ Команды выросли, нужна независимость
├─ Orders Service (своя БД)
├─ Products Service (своя БД)
├─ Users Service (своя БД)
├─ Notifications Service
├─ Analytics Service
└─ API Gateway для маршрутизации

Как это описать на собеседовании

Вариант 1: Если решение принимал ТА / архитектор

"На моём опыте, мы начали с монолита, потому что:

1. Размер команды — 3 разработчика, монолит был оптимален
2. Скорость разработки — нужно было выпустить MVP за 2 месяца
3. Операционная готовность — у нас не было опыта с микросервисами и Kubernetes

Когда DAU вырос до 100K, мы начали выделять критические сервисы:

• Payment Service (асинхронно обрабатывается, может падать независимо)
• Notification Service (очередь на Kafka/RabbitMQ)

Это дало нам баланс между сложностью и гибкостью."

Вариант 2: Если принимал участие в обсуждении

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

1. Разные SLA — Payment service требовал 99.99% uptime, а Analytics мог быть 95%
2. Разные требования к масштабированию — Поиск товаров требовал горизонтального масштабирования
3. Разные технологии — для Поиска мы выбрали ElasticSearch + Node.js, для обработки платежей — Go

Я предложил использовать Service Mesh (Istio) для управления сетевыми запросами, что упростило отслеживание и управление трафиком между сервисами."

Вариант 3: Если у вас не было такого выбора

"Я присоединился к проекту, который уже был монолитом. Но я участвовал в обсуждениях о расширении архитектуры:

1. Проблема — функция рекомендации товаров была CPU-bound, замораживала основной поток
2. Решение — я предложил выделить это в отдельный микросервис с очередью
3. Результат — рекомендации обрабатывались асинхронно, основной API стал быстрее на 40%

Основной принцип, который я усвоил: начни с монолита, выделяй микросервисы по мере необходимости (strangler fig pattern)."

Техническая архитектура, которую я бы рекомендовал

Для быстрого роста (0-100K DAU):

Монолит + Async Queue
├─ Node.js Express в main service
├─ RabbitMQ/Kafka для асинхронных операций
├─ Redis для кэша
├─ PostgreSQL для основных данных
└─ ElasticSearch для поиска

Для масштабирования (100K-1M DAU):

API Gateway + Микросервисы + Service Mesh
├─ Kong / AWS API Gateway
├─ Users Service (Node.js)
├─ Orders Service (Go или Rust)
├─ Products Service (Node.js + Elasticsearch)
├─ Payments Service (Go)
├─ Kafka для асинхронной коммуникации
├─ Kubernetes для оркестрации
└─ Prometheus + Jaeger для мониторинга

Ключевые выводы

1. Нет универсального ответа — выбор зависит от контекста
2. Монолит не плохой — это инструмент, подходящий для ранних стадий
3. Микросервисы дороги — не только в разработке, но и в операциях
4. Strangler Fig Pattern — лучший способ мигрировать с монолита
5. Правило большого пальца — начни с монолита, выделяй микросервисы по мере роста

На собеседовании главное показать, что ты понимаешь trade-offs и можешь обоснованно принимать архитектурные решения на основе контекста, а не моды.