Багатопродавцева платформа: розробка від MVP до масштабування

Архітектура багатопродавцевої платформи: від MVP до масштабування

Маркетплейс — одна з найскладніших платформ з точки зору архітектури. Одна помилка в розщепленні платежів — і гроші йдуть не туди. Ми розберемо ключові підводні камені на прикладі реальних проєктів, де кількість продавців перевищувала 10 000, а каталог товарів — 250 000 одиниць. Наприклад, в одному проєкті з 15 000 продавців та 500 000 товарів ми зіткнулися з проблемою N+1 запитів під час завантаження кошика. Рішення — матеріалізовані представлення та кеш Redis, що скоротило час обробки на 60%. Наш досвід показує: правильна архітектура з першого разу економить до 40% бюджету на доробках. Фінансові втрати від неправильної архітектури можуть сягати кількох мільйонів гривень.

Чому маркетплейс складніший за інтернет-магазин?

На відміну від звичайного магазину, маркетплейс керує кількома сторонами: покупець, продавець, платформа. Це породжує три критичні проблеми: розщеплення платежів, верифікацію відгуків та вирішення спорів. Кожна з них потребує окремого проєктування і часто — зовнішніх інтеграцій. Типова комісія маркетплейсу варіюється від 10% до 20% залежно від категорії товарів. Ключові метрики: LCP < 2.5 с, конверсія > 3%.

Проблема розщеплення платежів

Покупець платить одну суму, яка автоматично ділиться між продавцем і платформою. Stripe Connect — стандарт для західного ринку. Він пропонує три схеми: Direct (продавець бачить клієнта), Destination (гроші йдуть через платформу) та Separate charges + transfers (максимальна гнучкість для multi-vendor cart). У СНД використовують ЮKасу з API сплітування або CloudPayments через агентську схему. Згідно з документацією Stripe, Transfer створюється так:

import stripe
stripe.Transfer.create(
    amount=8500,  # у центах
    currency="usd",
    destination="acct_1BuAYuBnMOckkSJp",  # seller's connected account
    transfer_group="ORDER_95",
)

Проблема відгуків та рейтингів

Відгук має бути верифікований: тільки покупець, який фактично отримав товар, може залишити відгук. Тригер — зміна статусу замовлення на delivered або completed + N днів. Продавець може відповісти на відгук. Рейтинг продавця обчислюється за ковзним середнім, часто з ваговим коефіцієнтом за давністю (відсічка 90 днів, вага молодих відгуків — 0.4). Неверифіковані відгуки відфільтровуються, щоб уникнути накруток.

Проблема вирішення спорів

Спір (dispute) — сутність, що виникає при конфлікті: покупець відкриває спір, продавець відповідає, оператор виносить рішення. Таймаути: продавець відповідає протягом 3 днів, оператор вирішує протягом 5 робочих днів. Платіжна система виконує рішення (refund або transfer). У нашій практиці 85% спорів вирішуються без ескалації на оператора завдяки автоматичним правилам: якщо сума спору менша за $50, система повертає гроші покупцеві без участі оператора.

Як вибрати стек для маркетплейсу?

Вибір стеку залежить від масштабу та вимог до продуктивності. Для MVP достатньо Laravel + PostgreSQL + Meilisearch (пошук товарів). Для платформи з мільйонами товарів краще Django + PostgreSQL + Elasticsearch. На фронтенді Next.js забезпечує хороший SEO та швидкий TTFB. Черги та кеш — Redis. Зберігання файлів — S3-сумісне (Cloudflare R2, MinIO). Наші сертифіковані інженери Stripe та AWS гарантують якість.

Stripe Connect в 3 рази гнучкіший за ЮKасу для multi-vendor cart.

Порівняння платіжних підходів

Як ми будуємо маркетплейс

Наша команда має 7+ років досвіду в розробці складних платформ, запущено 15+ маркетплейсів. Наші інженери мають сертифікати з Stripe та AWS. Процес включає:

1. Аналітика — збір вимог, вибір стеку, прототипування платежів.
2. Проєктування — архітектура БД, схеми розщеплення, рольова модель.
3. Реалізація — API, адмінка, кошик, оплата, пошук, відгуки, спори.
4. Тестування — навантажувальне тестування, симуляція спорів, аудит безпеки.
5. Деплой — розгортання на хмарі, налаштування CI/CD, моніторинг.

Що входить у роботу

• Документація API у Swagger
• Вихідний код у репозиторії
• Доступи до панелей адміністратора
• Інструкція з експлуатації
• Навчання адміністраторів (до 2 годин)
• Технічна підтримка на місяць після запуску з гарантією відповіді протягом 24 годин

Терміни розробки

MVP (реєстрація продавців, каталог товарів, кошик, оплата з розщепленням, особисті кабінети, панель адміністратора) — 3–5 місяців. Повноцінна платформа з відгуками, спорами, аналітикою, мобільними додатками — 6–12 місяців.

Якщо ви плануєте запустити маркетплейс — зв'яжіться з нами для попередньої оцінки. Замовте аудит архітектури вашого маркетплейса — отримайте план оптимізації безкоштовно. Ми спеціалізуємось на розробці маркетплейсу, створенні маркетплейсу під ключ, впровадженні розщеплення платежів через Stripe Connect, системи відгуків, пошуку товарів, MVP маркетплейсу, багатопродавцевої платформи, комісії маркетплейсу, спорів на маркетплейсі та безпеки платежів.

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

Процес роботи

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

Що входить в роботу

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.