Разработка мобильного приложения для маркетплейса
Маркетплейс — не просто интернет-магазин с несколькими продавцами. Это три параллельных приложения в одном: покупатель, продавец, администратор. Архитектурные решения, принятые на старте, определяют, насколько сложно будет добавлять нового продавца или новый тип товара через полгода.
Где маркетплейсы ломаются технически
Каталог с многовендорными фильтрами. Стандартный UICollectionView / RecyclerView с paginated endpoint работает до тех пор, пока у вас не 50 продавцов с пересекающимися категориями. Проблема: фильтр «категория + продавец + диапазон цен + сортировка» при пагинации через offset даёт дубли, если продавец добавил товар между запросами страниц. Используем cursor-based pagination (after=<last_item_id>) — стабильнее при частом обновлении каталога.
Корзина с товарами от разных продавцов. Пользователь добавил товары от трёх продавцов — при checkout нужно либо разбить на три отдельных заказа, либо создать один составной заказ с sub-orders. Это бизнес-решение, но оно влияет на UI: разбивка по продавцам в корзине, отдельные статусы доставки, возможность оплатить частично. Архитектуру корзины CartService с поддержкой VendorGroup согласовываем на старте.
Real-time наличие товаров. Покупатель смотрит на товар, который в этот момент купили. Классика: товар добавлен в корзину, при checkout — out_of_stock. Хорошее решение: WebSocket-канал на детальной странице товара (wss://api/items/{id}/stock), который обновляет счётчик остатков в реальном времени. Менее дорогое: polling каждые 30 секунд через Timer при активном экране товара.
Приложение продавца
Отдельный target/модуль или отдельное приложение — зависит от объёма функциональности. Если продавец только управляет товарами и смотрит заказы — можно один target с role-based routing. Если продавцу нужна аналитика, управление складом, чат с покупателями — отдельное приложение.
Обязательные функции продавца:
- Добавление и редактирование товаров с фотографиями (загрузка в S3/Cloudinary через pre-signed URL прямо с устройства, без проксирования через сервер)
- Входящие заказы с push-уведомлениями (
FCM/APNsс высоким приоритетом для новых заказов) - Изменение статуса заказа: принят → в обработке → отправлен → доставлен
- Отчёт по продажам за период
Платежи в маркетплейсе
Самое сложное — split-payment: покупатель платит одну сумму, деньги расщепляются между продавцами и платформой. Stripe Connect, PayPal Marketplace или аналог. Stripe Connect: покупатель платит через PaymentIntent с transfer_data или application_fee_amount, деньги автоматически распределяются по Connected Account каждого продавца. На мобиле — стандартный Stripe SDK (stripe-ios, stripe-android) для UI карточной формы.
Если 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 для стейта корзины и каталога.
Процесс
Discovery и проектирование (роли, флоу заказа, платёжная схема) → UI/UX для обоих приложений → разработка core-модулей (каталог, корзина, заказы, платежи) → продавческий модуль → административная панель → нагрузочное тестирование каталога и checkout → публикация.
Ориентиры по срокам
MVP маркетплейса (каталог, корзина, checkout, базовое продавческое приложение): 6–10 недель. Полнофункциональная платформа с split-payment, real-time уведомлениями, поиском и аналитикой: 3–5 месяцев. Стоимость рассчитывается индивидуально после анализа требований.