Багатопродавцева платформа: розробка від 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 гарантують якість.