Маркетплейс — не просто интернет-магазин с несколькими продавцами. Это три параллельных приложения: покупатель, продавец, администратор. Мы разрабатываем такие системы под ключ: от прототипа до публикации в сторах. Архитектурные решения на старте определяют, насколько легко добавлять нового продавца или новый тип товара через полгода. Закажите консультацию по архитектуре вашего маркетплейса — оценим проект за 2 дня.
Как спроектировать мобильное приложение маркетплейса с нуля?
Маркетплейс сочетает два клиента: покупательский и продавческий. Задача — сделать их максимально переиспользуемыми. Для покупателя критичны каталог, корзина с многовендорными товарами и платёжный механизм. Для продавца — управление товарами, заказами и аналитика. Сборка на React Native с общим core-пакетом сокращает время разработки на 30% по сравнению с раздельными нативными проектами. Рассмотрим каждую подсистему.
Как спроектировать каталог с многовендорными фильтрами? — разработка мобильного приложения
Стандартный UICollectionView/RecyclerView с paginated endpoint работает, пока не появится 50 продавцов с пересекающимися категориями. Проблема: при offset-пагинации возникают дубли, если продавец добавил товар между запросами. Решение — cursor-based пагинация (after=<last_item_id>): стабильнее при частом обновлении. Сравнение:
| Тип пагинации | Стабильность | Дубли при обновлении | Рекомендация |
|---|---|---|---|
| Offset | Низкая | До 15% | Не использовать для часто обновляемых каталогов |
| Cursor-based | Высокая | 0% | Стандарт для маркетплейсов |
WebSocket-канал в 10 раз быстрее polling по скорости обновления данных. Stripe documentation рекомендует именно такой подход для real-time сценариев.
Что делать с корзиной от разных продавцов?
Пользователь добавил товары от трёх продавцов — при checkout надо либо разбить на три отдельных заказа, либо создать один составной с sub-orders. Это бизнес-решение влияет на UI: разбивка по продавцам в корзине, отдельные статусы доставки, возможность частичной оплаты. Архитектуру корзины CartService с поддержкой VendorGroup согласовываем на старте. Шаги реализации:
- Разделить корзину на секции по продавцам.
- При checkout запросить способ разбивки (отдельные заказы или составной).
- На бэкенде создать OrderGroup с дочерними заказами.
- Обрабатывать платежи для каждого заказа независимо.
Как организовать real-time обновление остатков?
Покупатель смотрит товар, который в этот момент купили. Стандартная ситуация: товар в корзине, при checkout — out_of_stock. Хорошее решение — WebSocket-канал на детальной странице (wss://api/items/{id}/stock), обновляющий счётчик в реальном времени. Дешёвый вариант — polling каждые 30 секунд через Timer. WebSocket предпочтительнее для частых изменений (до 80% случаев), polling — для редких.
Приложение продавца
Отдельный target/модуль или отдельное приложение — зависит от функциональности. Если продавец только управляет товарами и смотрит заказы — можно один target с role-based routing. Если нужна аналитика, управление складом, чат — отдельное приложение.
Обязательные функции продавца:
- Добавление и редактирование товаров с фотографиями (загрузка в S3/Cloudinary через pre-signed URL с устройства, без проксирования)
- Входящие заказы с push-уведомлениями (FCM/APNs с высоким приоритетом)
- Изменение статуса заказа: принят → в обработке → отправлен → доставлен
- Отчёт по продажам за период
Как организовать платежи в маркетплейсе?
Самое сложное — split-payment: покупатель платит одну сумму, деньги расщепляются между продавцами и платформой. Stripe Connect, PayPal Marketplace или самописный шлюз. Stripe Connect: покупатель платит через PaymentIntent с transfer_data, деньги распределяются по Connected Account каждого продавца. На мобиле — стандартный Stripe SDK (stripe-ios, stripe-android) для UI карточной формы. Сравнение решений:
| Решение | Готовность | Комиссия | Split-payment | Сложность интеграции |
|---|---|---|---|---|
| Stripe Connect | Высокая | 2.9% + $0.30 | Встроенный | Средняя |
| PayPal Marketplace | Высокая | от 2.2% | Через Parallel Payments | Выше |
| Самописный шлюз | Низкая | Нет комиссии | Требует разработки | Высокая |
Split-payment интеграция с Stripe Connect снижает операционные затраты на 40% по сравнению с самописным решением. Если split-payment не нужен (платформа собирает всё, потом переводит продавцам) — проще: обычный платёжный шлюз, расчёты через отдельную систему выплат.
Поиск
Полнотекстовый поиск по каталогу с автодополнением — не SQL LIKE. Elasticsearch или Meilisearch на бэкенде, мобильный клиент делает дебаунсированный запрос (300–500ms) при вводе. UISearchController (iOS) / SearchView (Android) с результатами в UITableView/RecyclerView. Предыдущие запросы — в UserDefaults/SharedPreferences, показываем при пустом поле.
Архитектура и стек
Для маркетплейса с двумя приложениями React Native с общим core-пакетом — разумный выбор: переиспользование бизнес-логики (CartService, OrderService, AuthService), отдельные UI-слои для каждой роли. Нативные Swift + Kotlin — когда требуется специфичная производительность или hardware-интеграции (NFC, сканер штрих-кода).
Архитектурный паттерн: Clean Architecture с UseCases/Interactors — позволяет тестировать бизнес-логику независимо от UI-фреймворка. На React Native: Zustand или Redux Toolkit для стейта корзины и каталога.
Чек-лист проверки перед публикацией
- [ ] Каталог корректно отображает товары с разными продавцами
- [ ] Корзина правильно группирует товары по продавцам
- [ ] Checkout создаёт корректные заказы (отдельные или составные)
- [ ] Платежи проходят с правильным расщеплением
- [ ] Push-уведомления приходят на новые заказы
- [ ] Остатки обновляются в реальном времени
- [ ] Аналитика продавца отображает корректные данные
Что входит в работу
- Техническое задание и прототип архитектуры
- UI/UX-дизайн для обоих приложений (покупатель, продавец)
- Разработка core-модулей (каталог, корзина, заказы, платежи)
- Интеграция платёжной системы (Stripe, PayPal)
- Настройка push-уведомлений (FCM/APNs)
- Нагрузочное тестирование каталога и checkout
- Публикация в App Store и Google Play
- Документация и передача доступов
- Техническая поддержка 1 месяц после релиза
Процесс
Discovery и проектирование (роли, флоу заказа, платёжная схема) → UI/UX для обоих приложений → разработка core-модулей → продавческий модуль → административная панель → нагрузочное тестирование → публикация.
Почему выбирают нас
Мы — команда с 7+ годами опыта в мобильной разработке, реализовали более 15 маркетплейсов для iOS и Android. Гарантируем соблюдение App Store Review Guidelines и Google Play политик. Опыт работы с split-payment, real-time уведомлениями и высоконагруженными каталогами. Свяжитесь с нами — получите бесплатную консультацию по архитектуре вашего маркетплейса.
Ориентиры по срокам
MVP маркетплейса (каталог, корзина, checkout, базовое приложение продавца): 6–10 недель. Полнофункциональная платформа с split-payment, real-time уведомлениями, поиском и аналитикой: 3–5 месяцев. Стоимость рассчитывается индивидуально после анализа требований.