Архитектура и платформа

ПО для маркетплейса

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

Попробовать бесплатноЗаписаться на техническую консультацию
Каждая возможность сначала существует как API
API-firstКаждая возможность сначала существует как API
Слой приложения без состояния; число реплик увеличивается
Горизонтальное масштабированиеСлой приложения без состояния; число реплик увеличивается
Возможность работы на вашем собственном сервере
Облако или on-premiseВозможность работы на вашем собственном сервере
База данных и файлы под вашим контролем
Владение даннымиБаза данных и файлы под вашим контролем

Почему архитектурные решения — самые дорогие в исправлении?

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

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

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

Архитектура

Слои приложения и данных

Слева — как делится бизнес-логика, справа — где лежат данные. С ростом масштаба решающей становится правая колонка.

Слои приложения

  • Слой API: каждая возможность сначала существует как эндпоинт, а интерфейсы его потребляют
  • Модульная бизнес-логика: заказы, платежи, доставка, продавцы — в отдельных модулях
  • Интерфейсы без привязки к поставщику: интеграции платежей, доставки и счетов подчинены контракту
  • Движок рабочих процессов: автоматизация по правилам задаётся без изменения кода
  • Слой витрины: фронтенд с серверным рендерингом, открытый для SEO
  • Админ-панель и панель продавца — разные интерфейсы, общий API

Слои данных и инфраструктуры

  • Реляционная база данных: заказы, платежи, выплаты и другие данные, требующие согласованности
  • Поисковый движок (Typesense): отделение поиска по каталогу от базы данных
  • Слой кэширования: часто читаемые данные каталога и контента не пересчитываются заново
  • Объектное хранилище: изображения товаров и файлы; раздача через CDN
  • Очереди и фоновые задачи: массовый импорт, уведомления и доставка вебхуков
  • Журналы операций и аудита
Технические возможности

Технические гарантии, которые даёт платформа

Мультитенантная изоляция данных

Данные продавцов разделены на уровне организации; каждый запрос проходит проверку области видимости. Доступ одного продавца к данным другого исключён архитектурно.

Ролевая модель доступа

Отдельные наборы прав для администратора площадки, продавца, сотрудника продавца и покупателя. Разрешения задаются на уровне ресурсов.

Выделенный поисковый слой

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

Горизонтальное масштабирование

Слой приложения работает без состояния; при росте трафика увеличивается число реплик. В дни акций мощности добавляются без простоя.

Архитектура кэша и CDN

Каталог и контент кэшируются, изображения раздаются через CDN. Число запросов, доходящих до исходного сервера, заметно снижается.

Движок рабочих процессов

Правила «условие — действие» задаются из панели; для новой автоматизации не нужен релиз.

Слой вебхуков и событий

Внутренние события передаются во внешние системы подписанными запросами; неуспешные доставки повторяются и ставятся в очередь.

Многоязычность и мультивалютность

Контент и каталог ведутся на уровне языка; структура URL и микроразметка формируются отдельно для каждого языка.

Слой безопасности

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

Витрина, открытая для SEO

Страницы рендерятся на сервере; поисковая система видит содержимое, не выполняя JavaScript. Микроразметка и управление canonical идут из коробки.

Управление версиями и развёртыванием

Тестовая, предпродакшн- и боевая среды разделены; обновления применяются контролируемо.

Расширяемость

Дополнительные модули и сторонние приложения подключаются через тот же слой API; код ядра не меняется.

Модель развёртывания

Сравнение облака, on-premise и гибрида

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

КритерийОблако (управляемое)On-premiseГибрид
Ответственность за серверыНа насНа васРазделена
Расположение данныхОблако в выбранном регионеВаш собственный дата-центрЧувствительные данные у вас, остальное в облаке
МасштабированиеДобавление мощностей быстрое и гибкоеОграничено ёмкостью оборудованияЗависит от слоя
Стартовые затратыНизкиеТребуются вложения в оборудованиеСредние
Требования соответствияДостаточно для большинства сценариевПодходит, если данные должны оставаться в странеПодходит при частичных ограничениях
Обслуживание и обновленияС нашей стороныПланируются с вашей ИТ-командойРазделены
Для кого

Каким командам подходит эта платформа?

Компании с собственной командой разработки

Ваша команда может написать собственный фронтенд на слое API, добавить свои модули и подключить систему к существующим. При этом вы продолжаете получать обновления ядра.

Слой API и вебхуков

Корпоративный ИТ и требования соответствия

Где хранятся данные, кто к ним обращается и как они резервируются — всё это закрепляется договором. Развёртывание on-premise и журнал аудита готовы для таких сценариев.

Высоконагруженные проекты

В проектах, где в дни акций трафик кратно растёт, выделенный поисковый слой, кэш и горизонтальное масштабирование работают вместе.

Тем, кто хочет headless

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

Headless-коммерция
Эксплуатация

Четыре вещи, за которыми следят после запуска

Мониторинг и оповещения

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

Резервные копии и восстановление

Регулярные копии и учения по восстановлению; важно не наличие копии, а возможность вернуться.

Дисциплина доступа

Доступ к боевой среде ограничен по ролям, а все операции фиксируются в журнале аудита.

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

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

FAQ

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

Вопросы, которые чаще всего задают технические команды и ИТ-руководители.

Четырьмя вещами. Первая — мультитенантность: данные тысяч продавцов должны быть изолированы в одной базе, а каждый запрос — проходить проверку области видимости. Вторая — авторизация: нужны отдельные наборы прав для администратора площадки, продавца, сотрудника продавца и покупателя. Третья — разделение заказа: заказ из одной корзины распределяется между несколькими сторонами, и каждая часть проходит свой жизненный цикл. Четвёртая — финансовое разделение: в каждой операции комиссия и выплата продавцу должны учитываться отдельными статьями.
Ключевое решение — отделить поисковый слой от базы данных. Поиск по каталогу работает на Typesense; устойчивость к опечаткам и многомерная фильтрация выполняются без нагрузки на базу. К этому добавляются слой кэширования и раздача изображений через CDN. Поскольку слой приложения работает без состояния, при росте трафика масштабирование идёт горизонтально — увеличением числа реплик; в дни акций мощности добавляются без простоя.
Да, развёртывание on-premise поддерживается. Этот вариант выбирают прежде всего в корпоративных сценариях, где данные должны оставаться в определённом месте. В этом случае ответственность за серверы и масштабирование лежит на вашей ИТ-команде, а обновления планируются совместно. Возможны и гибридные схемы, где чувствительные данные остаются у вас, а остальное — в облаке.
Вам. База данных и файловое хранилище под вашим контролем: при развёртывании on-premise — полностью в вашей инфраструктуре, при управляемом варианте — от вашего имени и в вашей собственности. Экспорт данных всегда доступен через API и инструменты массовой выгрузки; вы не оказываетесь запертыми в платформе.
Нет. Интеграции платежей, доставки и счетов подключаются через интерфейсы, не зависящие от поставщика; каждый поставщик реализует один и тот же контракт. Добавить нового — значит написать реализацию этого интерфейса, остальной код приложения не меняется. Можно также подключить несколько поставщиков одновременно и маршрутизировать по региону или условию.
Да. Платформа спроектирована как API-first, поэтому каждая возможность сначала существует как эндпоинт; готовая витрина — лишь один из слоёв, потребляющих этот API. Вы можете написать собственный фронтенд на любой технологии и использовать платформу как слой данных и бизнес-логики. Мобильное приложение потребляет тот же API, поэтому управление контентом остаётся в одном месте.
Не сломают, если расширения сделаны без изменения кода ядра. Дополнительные модули и сторонние приложения подключаются через тот же слой API, а бизнес-правила задаются в движке рабочих процессов; ни то, ни другое не затрагивается обновлениями версий. В сценариях, где ядро меняется напрямую, план обновлений прорабатывается совместно на уровне проекта.
Страницы витрины рендерятся на сервере; поисковая система видит содержимое, не выполняя JavaScript. Для страниц товаров, категорий и материалов формируется микроразметка, а управление canonical и многоязычная структура URL идут из коробки. Это позволяет страницам категорий и товаров — главному источнику органического трафика по мере роста каталога — оставаться индексируемыми.

Похожие страницы

Мультивендорная электронная коммерция

Деловая сторона вопроса: динамика двустороннего рынка, take rate и операции.

API-интеграция маркетплейса

Поверхность REST API, события вебхуков и паттерны интеграции.

Headless-коммерция

Написать фронтенд на своей технологии и использовать платформу как слой данных.

Все возможности маркетплейса

Полное описание модулей платформы и их технические детали.

Обсудим ваши архитектурные требования вместе

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

Записаться на техническую консультациюПосмотреть возможности

Вариант on-premise · Данные принадлежат вам · Поддержка 24/7