Архитектура маркетплейса: монолит

Коротко: Выбор между монолитом и микросервисами в 2026 году определяется не только нагрузкой, но и необходимостью соблюдения 289-ФЗ. Монолит подходит для быстрого старта и малых команд, позволяя дешево внедрить базовые функции. Однако для масштабирования и сложной обработки данных, требуемой законом, со временем потребуется переход на микросервисную архитектуру с разделением контуров безопасности и платежных шлюзов.

Кстати, в AmSales мы делаем разработку сайтов и приложений и ИИ-интеграцию и анализ звонков под ключ. Если нужна помощь - напишите нам.

Выбор архитектуры под требования закона 289-ФЗ

С 1 октября 2026 года правила игры для всех владельцев цифровых платформ изменились окончательно. Закон № 289-ФЗ «Об отдельных вопросах регулирования платформенной экономики в Российской Федерации» перевел маркетплейсы из категории «просто интернет-магазинов» в категорию строго регулируемых операторов. Теперь архитектура системы - это не только вопрос скорости загрузки страниц, но и вопрос юридической выживаемости бизнеса. Если ваша ИТ-структура не позволяет разделять потоки данных и четко фиксировать условия взаимодействия с партнерами, вы рискуете получить штрафы или блокировку.

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

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

При проектировании важно учитывать и свежие инициативы. В сентябре 2026 года на regulation.gov.ru появился проект второго пакета мер по регулированию. Это значит, что требования к отчетности и прозрачности будут только ужесточаться. Разработка маркетплейса сегодня - это прежде всего создание системы, которая способна генерировать доказательную базу для регулятора в автоматическом режиме. Монолит может справиться с этим на старте, но его гибкость в управлении сложными связями между субъектами платформы будет ограничена.

Монолитная архитектура: когда она выгодна стартапу

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

Основные преимущества монолита для нового игрока:

• Скорость развертывания первой версии продукта (MVP).
• Простота тестирования - вы проверяете одну систему, а не цепочку взаимодействий.
• Низкие затраты на инфраструктуру и DevOps-инженеров.
• Единая база данных, что упрощает консистентность информации.

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

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

Микросервисы для масштабирования крупной платформы

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

Главный плюс здесь - отказоустойчивость. Если сервис рекомендаций «завис» из-за слишком сложных вычислений, пользователи все равно смогут оформить заказ. Это критически важно для удержания клиентской базы. Кроме того, микросервисы позволяют использовать разные технологии для разных задач. Например, для быстрого поиска по миллионам товаров можно использовать одну базу данных (Elasticsearch), а для хранения транзакций и финансовых операций - другую, максимально защищенную и надежную (PostgreSQL).

Но не стоит забывать о цене. Микросервисы требуют серьезной инженерной культуры. Вам понадобятся специалисты по Kubernetes, Kafka, мониторингу и распределенным транзакциям. Стоимость владения такой системой в разы выше, чем у монолита. Вы тратите огромные ресурсы не только на написание бизнес-логики, но и на «клей», который соединяет эти сервисы между собой. Если ваша команда не готова к такой сложности, микросервисы станут не инструментом роста, а причиной постоянных сбоев.

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

Как архитектура влияет на проверку карточек товаров

Закон 289-ФЗ наложил на операторов платформ серьезные обязательства по контролю контента. Теперь маркетплейс обязан проверять карточки товаров до их публикации. Это не просто формальность, а юридическое требование. Если на платформу попадет запрещенный товар или товар с недостоверными характеристиками, ответственность ляжет на оператора. Это напрямую влияет на то, как должна быть устроена архитектура системы.

В монолите процесс проверки часто реализуется как линейный шаг в цепочке создания товара. Продавец нажимает «Опубликовать», система запускает скрипт проверки, и если все ок - товар появляется в базе. Это просто, но не масштабируемо. При большом потоке новых товаров (например, когда на платформу заходит крупный дистрибьютор с 50 000 SKU) такая линейная схема станет «бутылочным горлышком». Проверка будет длиться часами, и партнеры будут недовольны скоростью выхода на рынок.

Правильная архитектура для проверки карточек должна строиться как отдельный асинхронный сервис. Процесс выглядит так:

1. Партнер загружает данные через API или личный кабинет.
2. Товар попадает в статус «На модерации» и сохраняется в промежуточном хранилище.
3. Специальный сервис модерации (с использованием автоматических алгоритмов и, при необходимости, людей) обрабатывает запрос.
4. После успешной проверки статус меняется на «Активен», и товар попадает в основной поисковый индекс.

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

Обеспечение комплаенса и обработки персональных данных

Работа с данными в 2026 году - это минное поле. Роскомнадзор в 2026 году запланировал более 1000 обязательных профилактических визитов в отношении операторов, обрабатывающих персональные данные (ПД). Если ваша архитектура не соответствует требованиям по защите и обезличиванию данных, последствия будут фатальными. Недостаточно просто поставить хороший файрвол; нужно правильно спроектировать сам ИТ-контур.

Согласно Постановлению правительства от 1 августа 2025 г. № 1154, существуют четкие требования к методам обезличивания ПД. Если вы используете данные пользователей для аналитики, построения моделей рекомендаций или передачи сторонним маркетинговым сервисам, вы обязаны использовать утвержденные методы. В архитектуре это означает необходимость создания отдельного «аналитического контура». Данные из основного контура (где живут ФИО, адреса и телефоны) должны проходить через процесс обезличивания перед тем, как попасть в среду для Data Science или маркетинга.

Приказ Минцифры № 173 от 3 марта 2026 года также устанавливает методические рекомендации по подготовке требований к предоставлению обезличенных данных. Это значит, что при проектировании системы вы должны заранее продумать, как именно данные будут трансформироваться. Например, вместо точного адреса в аналитический модуль должен уходить только район или город, а вместо точного возраста - возрастная группа. Это не только требование закона, но и способ снизить риски при утечках.

Еще один важный момент - разделение прав доступа. В архитектуре маркетплейса не должно быть ситуации, когда разработчик или администратор базы данных имеет прямой доступ к «живым» персональным данным клиентов. Необходимо внедрять ролевую модель доступа (RBAC) и логировать каждое обращение к чувствительным данным. Помните, что при проверке регулятор будет смотреть не только на наличие согласий на обработку, но и на то, как технически реализована защита этих данных внутри вашей системы.

Интеграция цифрового рубля в архитектуру системы

С 1 сентября 2026 года вступили в силу новые правила расчетов. Если ваш маркетплейс имеет выручку за 2025 год более 120 млн рублей и вы системно используете эквайринг крупных банков, вы обязаны обеспечить возможность оплаты цифровыми рублями. Это не просто добавление новой кнопки в корзине, это фундаментальное изменение в финансовом модуле вашей архитектуры.

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

При проектировании финансового контура нужно учесть несколько нюансов:

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

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

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

Когда стоит выбирать монолит, а когда - микросервисы, вопрос часто упирается в экономику. Многие ошибочно полагают, что микросервисы всегда дороже. Это правда лишь отчасти. Если рассматривать краткосрочный период (первые 1-2 года), монолит однозначно дешевле в разработке и поддержке. У вас меньше серверов, меньше инфраструктурных расходов и меньше дорогих DevOps-инженеров в штате.

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

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

Типичные ошибки при проектировании ИТ-контура платформы

Проектирование архитектуры маркетплейса - это не только выбор между монолитом и микросервисами. Это создание сложной системы, где ошибки на уровне структуры могут стоить бизнесу лицензии или репутации. Мы выделили несколько самых распространенных промахов, которые совершают компании в 2026 году.

Первая ошибка - игнорирование требований по обезличиванию данных на этапе проектирования. Многие компании пытаются «прикрутить» обезличивание потом, когда аналитики уже начали работать с данными. Это невозможно сделать без переписывания всей структуры базы данных. В итоге компания либо нарушает закон, либо тратит в 5 раз больше денег на переделку систем, чем если бы заложила это сразу.

Вторая ошибка - отсутствие четкого разделения контуров безопасности. Часто разработчики используют одну и ту же базу данных для хранения публичной информации (описание товаров) и чувствительных данных (паспорта партнеров, платежные реквизиты). В случае даже незначительной уязвимости в публичном модуле, злоумышленники получают доступ ко всему массиву данных. Архитектура должна физически или логически изолировать критически важные данные.

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

Четвертая ошибка - отсутствие механизмов автоматического аудиторского следа. В эпоху 289-ФЗ невозможно полагаться на ручную проверку того, кто и когда изменил условия договора или цену товара. Если ваша архитектура не умеет автоматически записывать каждое изменение в неизменяемый лог, вы не сможете защититься в суде или при проверке регулятора.

Что запомнить:

• Закон 289-ФЗ первична: Архитектура должна поддерживать прозрачность условий и контроль карточек товаров с первого дня.
• Монолит для старта, микросервисы для роста: Не стройте сложную систему, если у вас еще нет стабильного потока заказов, но закладывайте модульность.
• Данные - это риск: Обезличивание и разделение контуров (аналитика vs транзакции) должно быть частью архитектурного плана.
• Платежи меняются: Цифровой рубль требует особого внимания к интеграции и финансовой прозрачности.
• Автоматизируйте комплаенс: Любое изменение в системе должно оставлять цифровой след для регулятора.