Маркетплейс — самый сложный тип e-commerce проекта. Тысячи продавцов, миллионы товаров, сложная логистика и финансы. Архитектурно это всегда микросервисы.
Главное отличие маркетплейса от интернет-магазина не в размере каталога, а в том, что товар вам не принадлежит. Появляется третья сторона — продавец, у которого свой личный кабинет, свои остатки, свои цены и свои деньги. Отсюда растут все сложности: комиссии, взаиморасчёты, модерация карточек, споры по возвратам, разные схемы доставки. Ниже — как это раскладывается на сервисы и что из этого нужно уже в первой версии.
Сервисы в маркетплейсе
- Catalog (товары, категории, фильтры)
- Search (Elasticsearch с автодополнением)
- User (покупатели, продавцы, админы)
- Cart (корзина, избранное)
- Order (заказы, статусы, история)
- Payment (Kaspi Pay, Halyk, рассрочка)
- Logistics (курьеры, FBO/FBS)
- Notifications (email, SMS, push)
- Reviews (отзывы, рейтинги)
- Analytics (BI, продавец, админ)
Разбиение на сервисы имеет смысл там, где части системы живут с разной нагрузкой и разной скоростью изменений. Каталог и поиск читаются в сотни раз чаще, чем пишутся, и масштабируются репликами. Заказы и платежи, наоборот, пишутся редко, но требуют строгих транзакций и аудита. Держать это в одном процессе с одной базой — значит масштабировать всё разом ради одной горячей части.
При этом дробить сразу на десять сервисов на старте — типичная ошибка. Разумный компромисс: монолитное ядро (каталог, корзина, заказы) плюс вынесенные наружу поиск, платежи и обработка изображений. Дальше выносите то, что реально мешает: обычно первым уходит сервис уведомлений, вторым — расчёты с продавцами.
Каталог и поиск: где ломается первым
Каталог маркетплейса отличается от каталога магазина тем, что структуру данных вы не контролируете. Продавцы грузят товары по-разному: один пишет «Кроссовки мужские 42», другой — «Обувь спортивная, размер 42, чёрные». Без нормализации атрибутов фильтры перестают работать через пару месяцев после запуска.
Отсюда два обязательных механизма. Первый — жёсткая схема категорий с обязательными атрибутами: если категория «Смартфоны», то бренд, объём памяти и диагональ заполняются из справочника, а не строкой. Второй — модерация карточек с очередью и автоматическими проверками: дубликаты, запрещённые категории, фото без фона, цена вне разумного диапазона.
Поиск на SQL по LIKE перестаёт работать примерно на 50-100 тысячах товаров. Elasticsearch (или OpenSearch) нужен не только ради скорости: он даёт морфологию, опечатки, фасетные фильтры с подсчётом количества и ранжирование по вашей бизнес-логике — товар в наличии и с быстрой доставкой должен стоять выше. Отдельно закладывайте двуязычность: в Казахстане запрос на казахском и русском должен находить одну и ту же карточку.
Платежи и расчёты с продавцами
Самая недооценённая часть проекта. Покупатель платит один раз, а деньги нужно разложить между площадкой и несколькими продавцами — заказ из корзины часто содержит товары разных магазинов. Дальше у каждой суммы своя судьба: удержание комиссии, компенсация доставки, холд до подтверждения получения, возврат при отказе.
На уровне архитектуры это означает отдельный финансовый контур: счета продавцов, проводки, реестры выплат, акты. Проводки должны быть неизменяемыми — исправление делается сторнирующей записью, а не UPDATE. Иначе первая же сверка с бухгалтерией продавца превращается в расследование.
Практическая деталь для Казахстана: рассрочка и покупки через Kaspi дают заметную долю оборота, и логика возвратов там своя. Заложите это в модель заказа сразу, а не «потом допилим» — переделка платёжного контура на живой площадке стоит дороже, чем весь остальной рефакторинг.
Логистика: FBO, FBS и статусы
FBO — товар лежит на вашем складе, вы отвечаете за упаковку и доставку. FBS — товар у продавца, он собирает заказ, вы забираете и везёте. Третья схема, DBS, — продавец везёт сам. Технически это три разных набора статусов и три разных SLA, и все они должны сходиться в одном интерфейсе покупателя.
Мобильная часть здесь не опция: продавцу нужно приложение для сборки и печати этикеток, курьеру — для маршрута и подтверждения выдачи. Это отдельный проект внутри проекта, и его стоит планировать вместе с основным — мобильная разработка для операционных ролей обычно проще витрины, но без неё склад работает в Excel.
Стек ZoomApps
Backend: Laravel или Symfony PHP. БД: PostgreSQL + Redis + Elasticsearch. Очереди: Redis Streams или RabbitMQ. Frontend: Next.js. Мобильные: iOS Swift + Android Kotlin.
Выбор стека здесь вторичен по отношению к решениям о данных. Ключевое: PostgreSQL как источник истины по заказам и деньгам, Redis для сессий, корзин и кэша карточек, Elasticsearch как производная от каталога, которую всегда можно пересобрать. Очереди нужны с первого дня — индексация товаров, отправка уведомлений и генерация превью не должны выполняться в запросе пользователя.
Next.js на витрине берём ради SSR: страницы категорий и карточек должны отдаваться готовым HTML, иначе органический трафик придётся выкупать рекламой. Для площадки с большим каталогом поисковое продвижение — основной канал, и техническая база под него закладывается на этапе архитектуры, а не после запуска.
Что делать в MVP, а что отложить
В первую версию входит минимум, при котором площадка зарабатывает: регистрация и модерация продавцов, загрузка товаров с проверкой, поиск с фильтрами, корзина и заказ, одна схема доставки, оплата с разделением сумм, кабинет продавца с заказами и отчётом по деньгам, админка с модерацией и настройкой комиссий.
Откладываются: программы лояльности, персональные рекомендации, аукцион рекламных мест, мультивалютность, сложная тарифная сетка комиссий по категориям, приложение покупателя. Последнее особенно — сначала адаптивная витрина, приложение после того, как стало понятно, что люди возвращаются.
Частые ошибки на старте: запуск с пустым каталогом (сначала 30-50 продавцов, потом реклама), отсутствие ролей и прав в админке, единая база без разделения на чтение и запись, и попытка сделать «как Wildberries» с первого релиза. Если задача проще — витрина со своим товаром — честнее делать интернет-магазин, он дешевле и запускается за недели.
Стоимость и сроки
MVP-маркетплейс: от 4 500 000 ₸ за 3 месяца. Полнофункциональный: от 12 000 000 ₸ за 6 месяцев. Wildberries-уровень: от 50 000 000 ₸ за 12+ месяцев.
Разброс объясняется не «сложностью дизайна», а количеством схем доставки, глубиной финансового контура и числом внешних интеграций: эквайринг, 1С, службы доставки, ЭДО. Каждая интеграция — это не только код, но и тестовый контур на стороне партнёра, который обычно выдаётся дольше, чем пишется.
Практический вывод: начинайте не с выбора фреймворка, а с описания трёх вещей — модель денег (кто кому и когда платит), модель товара (какие атрибуты обязательны) и модель доставки (какие схемы поддерживаете). Если эти три документа есть, разработка маркетплейса становится инженерной задачей с предсказуемым сроком. Если их нет, любая архитектура развалится на третьем месяце.