Микросервисы до Product-Market Fit: как стартап покупает сложность раньше клиентов

У стартапа из пяти инженеров ещё нет стабильного потока платящих клиентов. Модель монетизации меняется каждые две недели. Зато в репозитории уже красуются восемь отдельных микросервисов, Kafka и три базы данных.

Команда гордится архитектурой на вырост. Инвесторам показывают диаграммы с десятком узлов. В реальности стартап совершил классическую ошибку: он купил операционную сложность корпорации задолго до появления спроса.

Когда продукт ищет product-market fit (PMF), главный ресурс команды — скорость проверки гипотез. Если изменение кнопки в корзине требует правок в четырёх сервисах и трёх синхронных релизов, стартап теряет темп. Архитектура превращается в якорь.

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

👥 1. Микросервисы решают проблему масштаба людей, а не кода

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

Когда над проектом работают 200 инженеров, они не могут коммитить в один репозиторий без постоянных конфликтов. Им трудно тестировать код и координировать релизы. Микросервисы разделяют зоны ответственности между независимыми командами. Каждая группа развивает свой сервис автономно.

Большая компания (200 инженеров):
[Команда A] -> [Сервис платежей]
[Команда B] -> [Сервис каталога]
[Команда C] -> [Сервис доставки]

Ранний стартап (4 инженера):
[Те же 4 человека] -> пишут код и чинят баги во всех 8 сервисах одновременно

В стартапе закон Конвея работает против основателей. Четыре разработчика вынуждены переключать контекст между десятком проектов. Автономии нет: одни и те же люди пишут контракты, настраивают сборки и вручную связывают логи. Они получают накладные расходы распределённых систем без единственного их преимущества.

📉 2. До PMF главное преимущество — дешевизна ошибки

До достижения устойчивого спроса модель данных нестабильна. Сегодня подписка привязана к пользователю. Завтра отдел продаж просит продавать командные лицензии. Через месяц бизнес решает перейти на оплату за фактически потребленные ресурсы.

В модульном монолите такая перестройка прозрачна. Разработчик меняет схему базы данных в одной миграции, правит логику домена и закрывает задачу за два дня. Изменение атомарно. Риск рассогласования минимален.

В микросервисах простая смена бизнес-правила превращается в инженерный кошмар: нужно обновить контракты API в трех репозиториях, обеспечить обратную совместимость очередей и написать распределенные саги вместо обычного отката транзакции. Каждая гипотеза становится в пять раз дороже, и стартап погибает до того, как нащупает рынок.

💸 3. Скрытый операционный счёт: за что приходится платить

Локальный вызов метода в памяти процесса выполняется за доли микросекунды и гарантирован архитектурой ОС. Сетевой вызов между сервисами принципиально ненадежен: запрос может зависнуть, сервер может упасть посреди обработки, а повторная попытка способна дважды списать деньги с карты.

Монолит:
[ Метод A ] --(вызов в памяти за 0.001 мс, ACID-гарантия)--> [ Метод B ]

Микросервисы:
[ Сервис A ] --(сеть, DNS, таймауты, ретраи, идемпотентность, 45 мс)--> [ Сервис B ]

Чтобы распределённая система не разваливалась в проде, команда обязана внедрить взрослую инфраструктуру: distributed tracing через OpenTelemetry, circuit breakers, dead-letter queues и ключи идемпотентности. Для локального запуска разработчику требуется 32 ГБ оперативной памяти и связка из двадцати Docker-контейнеров. Вместо общения с пользователями время уходит на битву с манифестами Kubernetes.

🔗 4. Ложная изоляция: как рождается распределённый монолит

Большинство ранних команд строят не микросервисы, а худший антипаттерн индустрии — распределённый монолит. Код физически разрезан по разным папкам и репозиториям, но логические границы предметной области между ними отсутствуют.

Сервисы обмениваются десятками синхронных REST-запросов на каждый клик, а иногда используют общую базу данных. В итоге, чтобы задеплоить фичу, нужно синхронно обновить три сервиса строго по порядку, а падение сервиса уведомлений блокирует оформление заказов. Команда получает сетевые задержки и каскадные аварии, сохранив все минусы монолита.

🏛️ 5. Модульный монолит как прагматичный стандарт

Отказ от микросервисов на старте не означает согласие на хаотичный клубок кода. Золотая середина — модульный монолит. Это единый процесс и единая кодовая база, внутри которой действуют строгие архитектурные границы.

                    ┌────────────────────────┐
                    │    Модульный монолит   │
                    │                        │
                    │  [Каталог]  [Заказы]   │
                    │      ▲          │      │
                    │      │          ▼      │
                    │  [Биллинг] [Уведомления]│
                    └───────────┬────────────┘
                                │ (ACID-транзакции)
                                ▼
                    ┌────────────────────────┐
                    │    Единая база данных  │
                    └────────────────────────┘

Каждый модуль инкапсулирует свои данные и внутреннюю логику. Доступ из чужого модуля в таблицы базы напрямую запрещен архитектурными тестами — общение идет только через публичные интерфейсы в памяти. Это дает мгновенный онбординг, надежные транзакции, дешевый рефакторинг и полную готовность к безболезненному распилу в будущем.

🚦 6. Чек-лист: объективные триггеры для выделения сервиса

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

• Изолированный профиль нагрузки: транскодирование видео или генерация PDF утилизирует 100% CPU и должно масштабироваться отдельно от ядра продукта.

• Специфические требования безопасности: модуль платежей требует строгого аудита по стандарту PCI DSS и изоляции контура.

• Обособленная команда: за компонент отвечает отдельная группа из 6–8 инженеров с устоявшимся, неизменным контрактом взаимодействия.

• Стабильная доменная модель: логика модуля окончательно устоялась и не требует постоянных совместных релизов с остальным кодом.

Если этих условий нет, удерживайте монолит. Он сохранит скорость работы команды и позволит стартапу дожить до того дня, когда микросервисы станут приятной заботой растущего бизнеса.