Разработка B2B2C-платформы под ключ с изоляцией данных

Разработка B2B2C-платформы

Представьте: вы запускаете маркетплейс, где сотни партнёров продают услуги конечным клиентам. Данные разных партнёров не должны пересекаться — иначе утечка или нарушение NDA. Как организовать изоляцию без потери производительности? Это задача, которую мы решаем каждый день в течение 8 лет. За это время мы реализовали 45+ проектов для маркетплейсов и агрегаторов.

B2B2C-платформа объединяет оператора, бизнес-партнёров и конечных потребителей. Каждый уровень имеет свои интерфейсы и правила доступа. Разработка такой платформы под ключ включает трёхуровневую архитектуру, изоляцию данных и сложную финансовую логику. Мы используем современный стек: React, Node.js, PostgreSQL. В этой статье разберём ключевые аспекты: как настроить multi-tenancy, white-label и расчёты.

Платформа должна быть гибкой, чтобы подстраиваться под разных партнёров, и надёжной, чтобы работать без сбоев. Мы выбираем стек, который обеспечивает и то, и другое. Начнём с архитектуры.

Трёхуровневая архитектура

Платформа (оператор)
    ↓ предоставляет инфраструктуру
Бизнес-партнёры (B2B-клиенты, вендоры, поставщики услуг)
    ↓ обслуживают через платформу
Конечные потребители (B2C-пользователи)

Каждый уровень имеет свой интерфейс и правила доступа:

• Оператор — суперадмин, видит всё, управляет партнёрами
• Партнёр — видит только своих клиентов и свою аналитику
• Потребитель — видит только свой контент и услуги

Почему важна изоляция данных?

Данные разных партнёров не должны смешиваться — это вопрос безопасности и доверия. Мы используем три стратегии isolation:

• Row-Level Security (RLS) — единая база с tenant-фильтром, дёшево и масштабируемо до тысяч партнёров.
• Отдельные схемы PostgreSQL — лучшая изоляция, но сложнее миграции.
• Отдельные базы данных — максимальная изоляция для enterprise-партнёров.

Сравнение стратегий:

CREATE POLICY tenant_policy ON orders
USING (tenant_id = current_setting('app.tenant_id')::int);

Согласно PostgreSQL Documentation, RLS позволяет эффективно изолировать данные на уровне строк.

Как настроить white-label?

Партнёры хотят, чтобы платформа выглядела как их собственный продукт. White-label реализуется через:

• Кастомный домен (partner.yourdomain.com)
• Логотип и цветовая схема на основе CSS-переменных
• Кастомные email-шаблоны уведомлений

Middleware определяет тенант по домену, загружает настройки из базы и применяет тему. Этот подход работает в 2–3 раза быстрее, чем iframe-встраивание.

Что такое B2B2C multi-tenancy?

Архитектурный паттерн multi-tenancy предполагает, что одна инстанция приложения обслуживает множество клиентов (тенантов). В B2B2C-платформе каждый партнёр является тенантом. Разработка B2B2C платформы с изоляцией данных требует выбора стратегии multi-tenancy в зависимости от количества партнёров и требований к безопасности.

Расчёт взаиморасчётов

В B2B2C-платформе три стороны участвуют в транзакции:

• Потребитель платит X
• Партнёр получает X − комиссия платформы
• Платформа получает комиссию

Дополнительно учитываются реферальные программы, партнёрские скидки и промокоды. Типичная экономия на комиссиях при автоматизации расчётов — до 30%. Средняя стоимость лицензии на одного партнёра — от 10 000 рублей в месяц.

Аналитика по уровням

• Оператор видит общий оборот, активность партнёров, когортный анализ, отток
• Партнёр видит только своих потребителей, их активность, доходы, конверсии
• Потребитель видит свои заказы, историю, рекомендации

Аналитика партнёра изолирована — сравнительные метрики с другими партнёрами не показываются по умолчанию.

Онбординг партнёров

Чем проще зарегистрироваться и запустить работу, тем выше конверсия в активных партнёров. Типовой процесс:

1. Регистрация компании с документами
2. Wizard настройки (бренд, первый продукт)
3. Тестовый режим (sandbox-платежи, проверка интеграций)
4. Публикация в продакшн

Срок от регистрации до первой транзакции — не более 1–2 дней. Более 90% партнёров успешно проходят онбординг.

Что входит в работу

При заказе разработки B2B2C-платформы мы предоставляем:

• Архитектурная документация (ERD, sequence diagrams)
• CI/CD с изоляцией окружений
• Интеграция с платежными системами (Stripe, ЮKassa)
• Обучение команды партнёра
• Техподдержка на 3 месяца (стоимость — от 50 000 рублей в месяц)

Технический стек

Сроки

MVP B2B2C-платформы с управлением партнёрами, white-label, изоляцией данных и базовыми финансами: 4–6 месяцев. Бюджет на разработку MVP обычно составляет от 2 до 4 миллионов рублей. Полноценная платформа с маркетплейсом, мобильными приложениями и аналитикой: 8–14 месяцев.

Закажите разработку — и мы подготовим архитектуру под ваш проект. Оцените проект — свяжитесь с нами. Наши инженеры имеют сертификаты AWS и PostgreSQL, поможем выбрать оптимальную архитектуру под ваши задачи.

Разработка корпоративных порталов и внутренних систем

Мы занимаемся разработкой корпоративных порталов — CRM, ERP, LMS и Intranet. Каждый такой проект начинается не с вёрстки лендинга, а с того, как бизнес-правила лягут в архитектуру: кто видит какие данные, как синхронизируются 1С и учётная система, как 500 контактов превращаются в 500 000 без падения производительности. За 7 лет мы реализовали более 40 порталов для компаний с численностью от 50 до 5000 сотрудников. Оценим ваш проект за два рабочих дня — просто свяжитесь с нами.

Публичный сайт можно запустить без детального проектирования — итеративно править по фидбеку. С корпоративным порталом так не работает: стоимость исправления архитектурных решений после запуска на 200 пользователей несопоставимо выше. Поэтому мы уделяем 70% времени аналитике и прототипированию, а код пишем только после согласования ролевой матрицы и интеграционной схемы.

Три зоны, где чаще всего принимаются плохие решения, — модель прав доступа, производительность на больших данных и real-time обновления.

Как построить ролевую модель для 30 отделов?

Модель прав доступа. «Менеджер видит только своих клиентов, руководитель отдела — весь отдел, директор — всю компанию, но финансовые данные — только финансовый директор и выше». Это не три роли — это матрица из ролей, разрешений, организационных единиц и владения записями. Если это реализовать через if ($user->role === 'manager') в контроллерах — через полгода код станет неподдерживаемым.

Правильный подход: Spatie Laravel Permission для базовой ролевой модели + Policy классы для object-level permission (can('view', $deal) проверяет не только роль, но и владение). Для сложных иерархических структур — ABAC (Attribute-Based Access Control) вместо RBAC.

Производительность на больших данных. CRM с 500 000 контактов, фильтрация по 10 полям, сортировка по активности — это задача, где наивная реализация выдаёт 15-секундные запросы. Composite indexes, денормализация агрегатов (last_activity_at на самой записи вместо MAX по связанной таблице), Elasticsearch для full-text поиска по контактам.

Real-time обновления. Несколько сотрудников работают с одним документом или задачей. Без WebSocket — постоянные setInterval с polling каждые 5 секунд, лишняя нагрузка на сервер, задержка обновлений. Laravel Broadcasting + Pusher/Soketi или собственный WebSocket сервер на Node.js — для уведомлений и изменений в реальном времени.

CRM-системы

Типичный набор: контакты, компании, сделки, активности, воронка продаж, отчёты. Технически это несложно. Сложность — в деталях.

Pipeline с кастомными стадиями. Каждая компания хочет свою воронку. Стадии должны быть настраиваемыми без деплоя. Таблица pipeline_stages с position, color, is_final, probability — и drag-and-drop для изменения порядка на UI (React DnD или dnd-kit).

История изменений. Кто и когда изменил статус сделки, поменял ответственного, добавил заметку. Audit log через Observer или spatie/laravel-activitylog. На UI — timeline с фильтрацией по типу активности.

Интеграция с почтой. IMAP/SMTP для подключения корпоративного ящика, автоматическая привязка входящих писем к контактам по email-адресу. Это надёжно работает только при правильной обработке bounce, spam, автоответов — нужна фильтрация.

Почему ERP — не про код, а про данные?

ERP — это когда CRM, склад, производство, бухгалтерия и HR объединены в единую систему. Полный ERP с нуля — редкая задача (обычно интегрируются с существующими системами), но модульные системы под конкретный бизнес — регулярная.

Ключевой принцип: финансовые операции должны быть неизменяемыми. Не UPDATE orders SET status = 'cancelled' — а создание новой записи order_cancellations с ссылкой на исходный заказ. Это принцип immutable ledger, который упрощает аудит и reconciliation.

Интеграция с 1С — почти всегда часть ERP-проекта. Двусторонняя синхронизация: из 1С в портал (справочники, остатки, цены) и из портала в 1С (заказы, документы). RabbitMQ как шина событий между системами надёжнее прямого HTTP-взаимодействия — в случае недоступности 1С сообщения ждут в очереди.

Как устроены LMS: платформы обучения

Learning Management System — это курсы, модули, уроки, тесты, сертификаты, прогресс пользователей.

Видео-контент — самая нагруженная часть LMS. Хранить видео на собственном сервере и отдавать через Nginx — плохая идея: дорого, медленно, нет адаптивного битрейта. Правильно: загрузка в S3/Cloudflare R2, транскодирование через AWS Elemental MediaConvert или Mux, HLS-плейлист для адаптивного стриминга через Video.js или Plyr.

Прогресс просмотра — через периодическую отправку watch_position с фронтенда (каждые 10–30 секунд), хранение в Redis с периодической синхронизацией в PostgreSQL. Не сохранять каждую секунду в БД — это убьёт производительность.

SCORM-совместимость — если нужна интеграция с корпоративными тренинговыми материалами. Отдельный модуль, есть готовые библиотеки (scorm-again).

Intranet и HR-порталы

Корпоративный интранет: новости, документы, оргструктура, HR-процессы (отпуска, заявки, KPI).

Оргструктура в базе данных — это иерархическая структура. Adjacency list (parent_id на каждой записи) прост в реализации, но медленен при рекурсивных запросах. Nested Sets или Closure Table быстрее для чтения иерархии, сложнее при изменениях. В PostgreSQL — рекурсивные CTE (WITH RECURSIVE) с adjacency list — баланс между простотой и производительностью.

Согласование документов и заявок — workflow engine. Простые линейные согласования (сотрудник → менеджер → HR → бухгалтер) можно сделать без специального движка. Нелинейные (параллельные ветки, условные переходы, делегирование) — стоит рассмотреть готовые решения: Temporal.io для workflow orchestration или собственный конечный автомат на базе state-machine паттерна.

Что входит в работу

При заказе разработки корпоративного портала вы получаете:

• Архитектурную документацию (ER-диаграммы, схема интеграций, матрица ролей)
• Полный код в Git-репозитории с CI/CD
• Доступы к инфраструктуре (хостинг, базы данных, хранилища)
• Обучение администраторов и ключевых пользователей (2–3 сессии)
• Гарантийную поддержку на 3 месяца после запуска

Наши принципы проектирования опираются на официальную документацию Laravel по авторизации (Policies) и рекомендации по работе с очередями.

Технический стек для порталов

Ориентиры по срокам

Стоимость рассчитывается индивидуально после детальной аналитики требований и ролевой модели. Чтобы получить предварительную оценку, напишите нам — мы проанализируем вашу задачу и предложим оптимальное решение под ключ.