Монолит или микросервисы для интернет-магазина: критерии выбора

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

21 октября 2026Технологии13 мин чтения

---

Монолит или микросервисы: с чего начать выбор

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

Модульный монолит

Серверная часть выпускается как одно приложение, а код разделён по бизнес-функциям: каталог, цены, заказы, остатки. Модули взаимодействуют через согласованные интерфейсы, а не меняют внутренние данные друг друга произвольно. База данных может быть общей, но правила доступа к таблицам и ответственность за изменения остаются явными. Такое устройство позволяет удерживать границы без сетевых вызовов между каждой парой модулей.

Микросервисная архитектура

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

Подключение внешнего платёжного провайдера или 1С встречается при обоих подходах. Само наличие интеграций не делает приложение микросервисным. Общее устройство серверной части разобрано в статье «Бэкенд мобильного приложения: стек, API и админка»; здесь сравниваем последствия архитектурного выбора.

Плюсы и ограничения двух подходов

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

Независимый выпуск имеет ценность, если команда действительно использует его. Когда каждый сервис обновляют только вместе с остальными, сетевые границы добавляют сопровождение без ожидаемой автономии.

Границы сервисов: где проходит ответственность

Границу проводят вокруг бизнес-правила, которое можно изменять без постоянного согласования с соседними функциями. Важны владелец данных, причины изменения и допустимый способ взаимодействия. Разделение только по таблицам «товары», «строки заказа», «скидки» часто заставляет сервисы обращаться друг к другу для каждого действия покупателя.

Совместные изменения

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

Ответственность за изменение данных

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

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

Согласованность данных: заказ, резерв и оплата

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

Транзакции внутри монолита

Если заказ и резерв находятся в одной базе, их изменения можно подтвердить или отменить вместе. Такая транзакция защищает локальные данные. Внешнее списание денег она не отменяет: для платёжного провайдера всё равно нужны отдельные статусы, обработка уведомлений и сверка результата.

Обработка частичных сбоев

Учебный сценарий: заказ получает статус «ожидает оплаты», склад подтверждает резерв, затем магазин запрашивает платёж. При отказе оплаты резерв освобождают по согласованному правилу. Если результат неизвестен из-за разрыва связи, сначала запрашивают состояние платежа. Повторять списание без проверки нельзя.

Последовательность локальных операций с действиями компенсации называют сагой. Компенсация — самостоятельное бизнес-действие, например снятие резерва, а не мгновенный откат всей системы. Такой подход описан в документации по шаблону Saga.

Обработка повторов

Каждой операции назначают уникальный ключ: повтор с тем же ключом не должен создавать второй заказ или второй платёж. Это свойство называется идемпотентностью. Для надёжной передачи событий запись об изменении и исходящем сообщении можно сохранять одной локальной транзакцией, а отправлять отдельно. Transactional Outbox в документации AWS объясняет этот механизм; получатели всё равно должны учитывать повторную доставку.

Для интеграции магазина с ERP и 1С заранее определяют источник остатков, срок резерва, порядок сверки и допустимое отставание данных. Значение «оплачено» покупатель должен получать из подтверждённого состояния, а не из факта нажатия кнопки.

Производительность, интерфейс и мониторинг

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

Масштабирование отдельной функции

Если во время акции нагрузка растёт преимущественно на поиск, его выделение может уменьшить объём ресурсов, добавляемых остальной системе. Сначала нужно подтвердить, что задержка возникает именно в поиске. Если причина в общей базе или медленном внешнем ответе, дополнительный сервис может сохранить прежнее ограничение. Проверку строят по сценариям нагрузочного тестирования, а не по числу зарегистрированных покупателей.

Влияние на покупательский сценарий

Архитектура серверной части сама по себе не определяет дизайн сайта или приложения. Она влияет на доступность действий: можно ли показать каталог при недоступных рекомендациях, повторить оплату без дубля, объяснить ожидание подтверждения. Для каждого зависимого действия задают время ожидания и понятное состояние интерфейса.

Сигналы для диагностики

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

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

Скорость разработки зависит от самостоятельности команд

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

Один общий план работ

Для команды, которая одновременно меняет каталог, корзину и оплату, единый выпуск сокращает число согласований между версиями. В модульном монолите всё равно нужны автоматические проверки границ: иначе общий код постепенно связывает функции, и локальная правка затрагивает весь продукт.

Несколько автономных направлений

Отдельные команды поиска, заказов и логистики могут развиваться независимо, если договорились о форматах запросов и событий. Нужны совместимость старых и новых версий, порядок вывода устаревших интерфейсов и владелец каждого сервиса. Готовность команды стоит проверить до миграции; соответствующие вопросы собраны в оценке готовности к микросервисам Microsoft.

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

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

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

Дополнительная эксплуатационная нагрузка может окупаться, если автономная команда чаще выпускает нужные бизнесу изменения или отдельное масштабирование сокращает подтверждённые расходы. Это гипотеза для расчёта и измерения; универсального процента экономии для интернет-магазинов нет.

Сатурн и Сыроварня: требования из клиентских сценариев

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

Сатурн: региональные склады и 1С

В кейсе Сатурна описаны каталог более 30 000 товаров, работа более чем в 20 городах, региональные склады и интеграция с 1С. Для такой задачи нужно согласовать, откуда приходят остатки и цены, как выбирается склад и когда резерв считается подтверждённым. Число городов не предписывает отдельный сервис на каждый регион.

Сыроварня: оформление связано с оплатой

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

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

Матрица выбора по масштабу магазина и команде

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

Постепенный переход

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

На переходном этапе особенно опасна несогласованная запись в старую и новую базы. Нужны один согласованный путь изменения, сверка данных и проверенный порядок восстановления. Смежный выбор между улучшением текущего кода и полной заменой разобран в статье «Рефакторинг или переписывание приложения».

Итог: как принять архитектурное решение

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

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

Часто задаваемые вопросы

Чем монолит отличается от микросервисов?

Монолит выпускается как единое серверное приложение. В модульном варианте его код разделён по бизнес-функциям с явными правилами взаимодействия. Микросервисы работают отдельно, обмениваются запросами или сообщениями и владеют своими данными. Их преимущество проявляется при независимых изменениях и масштабировании. За это приходится поддерживать сетевые взаимодействия, совместимость интерфейсов, наблюдение за системой и согласованность операций между сервисами.

Когда интернет-магазину нужны микросервисы?

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

Что такое модульный монолит?

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

Микросервисы работают быстрее монолита?

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

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

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

Что дороже поддерживать: монолит или микросервисы?

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

Можно ли перейти от монолита к микросервисам постепенно?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.

Никита БережновРуководитель отдела бэкенда