Выбор начальной архитектуры

Все примеры в статье соотносятся со сквозным кейсом сайта: высоконагруженный маркетплейс. Цель — дать понятные критерии выбора архитектуры на старте: монолит-слойный, модульный монолит, микросервисы.

Ключевые факторы выбора

• RPS / нагрузка: пик, среднее, рост в 12–24 мес.
• Сроки и ресурсы: дедлайны, размер и опыт команды.
• Доменные границы: стабильность модели, число поддоменов, независимость изменений.
• НФТ (нефункциональные требования): SLA, латентность, масштабирование, отказоустойчивость, комплаенс.
• Инфраструктура: CI/CD, мониторинг, трассировка, service mesh, API Gateway, observability.
• Данные: объём, согласованность, требования к транзакциям, GDPR / PII.
• Оргструктура: количество команд, закон Конвея, независимые релизы.
• Интеграции: число внешних систем, синхронность, надёжность каналов.

Вариант 1. Слойный монолит

Когда брать

• Небольшой сервис, низкий и предсказуемый RPS (< 100–300), узкий домен.
• Жёсткие сроки, 1–3 разработчика.
• Высокая транзакционная целостность важнее горизонтального масштабирования.

Плюсы

• Быстрая скорость разработки (TTM), простая отладка и деплой, транзакции «в лоб».
• Минимальные оверхеды DevOps.

Риски

• Рост кода → эрозия границ, Big Ball of Mud.
• Сложно выделять части без предварительной модульной дисциплины.

Сигналы к миграции

• Частые конфликты релизов, разные темпы изменений по областям.
• Больше 2 команд или приближается к 50k+ LOC; высокие НФТ.

Примеры подходящих проектов

Сервис уведомлений, простой каталог товаров, утилитарный продукт с одним доменом, MVP стартапа.

Вариант 2. Модульный (многомодульный) монолит

Когда брать

• Потенциально крупный продукт, нужен быстрый старт.
• Ожидается рост команд и доменов, но один артефакт пока удобнее.
• Нужна готовность к «безболезненному» распилу на микросервисы (Strangler Fig в будущем).

Плюсы

• Исполняется как монолит, но с границами модулей (domain-first).
• Нет сетевых задержек, транзакции проще.
• Подходит для команды 5–7 человек.
• Средняя скорость разработки (модули нужно синхронизировать как микросервисы).
• Средние оверхеды DevOps (одна БД на модуль или сервисы очередей / REST для взаимодействия).

Риски

• «Ложные» зависимости между модулями, утечки в shared-модуль.
• Сложнее, чем слойный монолит — границы надо контролировать на ревью.
• Накладные расходы на взаимодействие между модулями.
• Разрастание кода — тяжелее работать в IDE.

Сигналы к распилу на микросервисы

• Узкие места по ресурсам (CPU / IO) локализованы в конкретных модулях.
• Нужны независимые масштабы / релизы / квоты / лимиты на модуль.
• Команда разрастается на несколько независимых.
• Необходимо отдать на аутсорс отдельные модули.
• Слишком большая кодовая база (более 3 команд или 200k+ LOC, высокие НФТ).

Примеры подходящих проектов

E-commerce средней сложности, B2B-платформа с несколькими доменами, продукт с чёткими бизнес-разделами но без жёстких требований к горизонтальному масштабированию.

Вариант 3. Микросервисы

См. также структурные паттерны микросервисов и распределённые паттерны — без них микросервисная архитектура не работает.

Когда брать

• Крупный проект, нет жёстких сроков, сильная команда и DevOps.
• Разные домены с разными НФТ, необходима независимая эволюция.
• Много интеграций.
• Работа нескольких команд.
• Высокие требования отказоустойчивости.

Плюсы

• Независимые релизы, масштабирование, отказоустойчивость на уровне сервиса.
• Чёткие границы владения данными, изоляция сбоев.
• Подходит для разработки большим количеством команд.
• Разработка больших проектов (150k+ строк кода).
• Можно использовать разные стеки в разработке.

Риски и стоимости

• Сетевые издержки, согласованность через SAGA, сложная трассировка.
• Высокий порог инфраструктуры (gateway, BFF, CI/CD, observability, contracts).
• Самая дорогая стоимость в разработке.
• Дорогая стоимость ошибки при неправильном проектировании.

Обязательные правила

• Чёткая карта поддоменов и границы данных (одна БД на сервис).
• Контракты (OpenAPI / AsyncAPI) и контрактные тесты — обязательны.
• Строгая SLO / SLA, бюджет латентности, idempotency, retry / backoff (см. resilience-паттерны).
• BFF на клиент: композиция данных, кэш, изоляция от чатов сервисов.

Когда не брать

• Нет опыта или инфры, срок «вчера», домен нестабилен, маленькая команда.

Примеры подходящих проектов

Маркетплейсы (наш сквозной кейс), банковские core-системы, SaaS-платформы с десятками независимых модулей, системы с высокими SLA и пиковым RPS 1k+.

Чек-лист

Считаем баллы — за каждое «Да» один балл:

Вопрос	Да
Сроки не жмут?	☐
RPS высокий (>250) или пики критичны?	☐
Доменов ≥ 5, независимые изменения?	☐
Нужны независимые релизы команд?	☐
Сложные НФТ (SLA 99.95%+, p95 < 100мс, комплаенс)?	☐
Развитие системы на годы вперёд?	☐

Итого баллов:

• 0–2 балла → слойный монолит
• 2–4 балла → модульный монолит
• 4–6 баллов → микросервисы

Главное правило

Не выбирайте микросервисы из-за моды. Они дают свободу масштабирования и независимых релизов ценой инфраструктурной сложности и сетевых граблей. Маленькому проекту с одной командой проще и быстрее жить с монолитом — а потом, если домен вырастет, безболезненно мигрировать через Strangler Fig.

Ссылки

• Кейс: маркетплейс — где нужны микросервисы по объективным причинам.
• Структурные паттерны микросервисов — обвязка, без которой микросервисы не живут.
• Распределённые паттерны — Saga, Outbox, идемпотентность.
• Паттерны отказоустойчивости — Retry, Circuit Breaker, Bulkhead.
• DDD: стратегические паттерны — Bounded Context как основа модульного разделения.