Архітектура маркетплейсу: чим вона відрізняється від класичного e-commerce

Класичний інтернет-магазин і маркетплейс зовні можуть виглядати схоже, але під капотом це різні системи.
Маркетплейс — це платформа для взаємодії багатьох бізнесів та користувачів, і більшість проблем у таких проєктах виникає саме через архітектуру.

1. Структура додатку: моноліт vs мультисервіс

У типовому e-commerce досить монолітної архітектури (наприклад, Laravel + MySQL або Shopify).
Для маркетплейсу така модель швидко стає вузьким місцем.
Тут зазвичай застосовують:

• модульну або мікросервісну архітектуру,

• окремі сервіси для авторизації, каталогу, оплати, логістики, звітності.

Це дозволяє масштабувати кожен сервіс окремо (наприклад, пошук або платіжний модуль при пікових навантаженнях).

Приклад:
Amazon і Rozetka використовують сервісно-орієнтований підхід — пошук і фільтри працюють окремо від обробки замовлень і фінансових операцій.

2. Користувачі та ролі

У класичному e-commerce є 2 ролі: клієнт і адміністратор.
У маркетплейсі мінімум 3:

• покупці,

• продавці,

• адміністратори платформи.

Це накладає вимоги на:

• систему авторизації та верифікації (KYC, підключення BankID, SMS, email),

• управління правами доступу,

• окремі особисті кабінети для різних типів користувачів.

3. Каталог і дані товарів

У e-commerce каталог і ціни контролює один бізнес.
У маркетплейсі — десятки чи тисячі продавців, кожен зі своїми правилами.

Тому потрібні:

• окремий сервіс для каталогів із підтримкою багатьох продавців,

• API або CSV/XLS-імпорт,

• контроль дублів, модерація, багатомовність,

• система оновлення цін і залишків (синхронізація з ERP продавців).

У Rozetka та Prom.ua використовується імпорт із 1С, SAP, Odoo, а зміни оновлюються через шини даних (наприклад, Kafka або RabbitMQ).

4. Оплата та фінанси

У звичайному магазині єдина точка прийому платежів.
У маркетплейсі платформа — це посередник між покупцем і продавцем.

Потрібно реалізувати:

• split-payments — автоматичний розподіл коштів між кількома сторонами,

• комісії та роялті платформи,

• виплати продавцям (payouts) із різною періодичністю,

• повернення коштів і бухгалтерські звіти.

Технічно це роблять через інтеграцію з платіжними шлюзами (LiqPay, WayForPay, Stripe Connect, Payoneer).

5. Замовлення та логістика

У маркетплейсі кожен продавець може мати свої склади, тарифи й умови доставки.
Тому:

• модуль логістики має бути гнучким,

• система повинна підтримувати multi-warehouse,

• API для інтеграції з службами доставки (Нова Пошта, Meest, DHL тощо).

6. Пошук і продуктивність

Чим більше продавців і товарів, тим складніше пошук.
У класичних рішень SQL-запитів часто недостатньо.
Застосовують:

• спеціалізовані пошукові рушії (Elasticsearch, OpenSearch, Algolia),

• кешування частих запитів (Redis, Memcached),

• CDN для медіафайлів.

Це критично для швидкодії: користувач очікує результат за секунди навіть при мільйонах товарів.

7. Модерація, безпека та аудит

Оскільки контент створюють продавці, маркетплейс має:

• інструменти для автоматичної модерації фото, текстів, категорій,

• систему флагів і скарг,

• аудит усіх дій у системі,

• захист персональних даних і фінансових транзакцій (GDPR, PCI DSS).

8. Особливості розробки та командна робота

Розробка маркетплейсу рідко буває швидким MVP.
Типовий підхід:

1. Discovery-етап – збір вимог, архітектурне проєктування.

2. Дизайн і прототипи – створення клієнтських і вендорських кабінетів.

3. Побудова бекенду й API – авторизація, товари, платежі.

4. Фронтенд та мобільні додатки – веб і мобільні інтерфейси.

5. Інтеграції – з ERP, платіжними та логістичними сервісами.

6. Тестування й безпека.

7. Підтримка і масштабування.

У команді зазвичай працюють:

• архітектор або техлід,

• back-end та front-end розробники,

• DevOps для CI/CD та масштабування,

• QA-інженери для навантажувального тестування,

• product-/project-manager для координації процесу.

Приклади технологічних стеків

• Rozetka – власна PHP/Laravel-платформа + мікросервіси, Elasticsearch, Redis, Kubernetes.

• Prom.ua – адаптований OpenCart із модульною структурою та власними сервісами для логістики та фінансів.

• Etsy – сервісно-орієнтована архітектура з Ruby on Rails, Go та Cassandra, масштабована під глобальну аудиторію.

Висновок

Маркетплейс відрізняється від e-commerce не лише бізнес-моделлю, а й архітектурою.
Це платформа, що поєднує десятки зовнішніх систем і має витримувати високі навантаження, гнучко масштабуватись і залишатися безпечною.

Успіх проєкту на 70% залежить від правильних технічних рішень на старті: продуманої архітектури, обраного стеку технологій та інтеграцій.