Ошибки проектирования БД маркетплейса

Коротко: Проектирование базы данных маркетплейса сегодня требует учета жестких требований 289-ФЗ и 152-ФЗ. Ключевые риски связаны с невозможностью отследить историю изменения условий договоров, отсутствием версионирования оферт, ошибками в проверке контрагентов через ЕГРЮЛ и несоблюдением сроков уведомления селлеров. Ошибки в архитектуре ведут к штрафам до 500 тыс. рублей и блокировкам в реестре Минэкономразвития.

Кстати, в AmSales мы делаем разработку сайтов и приложений и ИИ-интеграцию и анализ звонков под ключ. Если нужна помощь - напишите нам.

Архитектура данных под требования закона 289-ФЗ

С 1 октября 2026 года правила игры для цифровых платформ изменились радикально. Теперь маркетплейс - это не просто витрина, а юридически значимый посредник, статус которого подтверждается включением в специальный реестр Минэкономразвития РФ. Если ваша аудитория превышает 100 тыс. человек в сутки или объем сделок перевалил за 50 млрд рублей, вы обязаны соответствовать новым стандартам. Проектирование базы данных маркетплейса начинается не с таблицы товаров, а с моделирования юридических связей.

Главная системная ошибка - попытка использовать упрощенную модель "пользователь - товар - заказ". Закон о платформенной экономике 289-ФЗ требует четкого разграничения ответственности. В БД должна быть жестко зафиксирована роль платформы: вы не являетесь продавцом, и это должно быть отражено в метаданных каждой карточки товара. Если архитектура не позволяет на лету менять статус отображения (например, добавлять дисклеймер о том, что условия поставки устанавливает именно селлер), это создает юридические риски.

Требования к структуре данных

Архитектура должна поддерживать следующие сущности:

• Реестровый статус платформы (дата включения, номер записи в реестре Минэкономразвития).
• Параметры аудитории и объема транзакций для ежегодного подтверждения статуса.
• Разграничение прав доступа: маркетплейс, селлер, покупатель, курьерская служба.
• Механизм фиксации условий продвижения, чтобы исключить манипуляцию поисковой выдачей.

Многие разработчики забывают, что 289-ФЗ накладывает обязательства по прозрачности алгоритмов. Хотя сами алгоритмы ранжирования - это код, их параметры (например, вес рекламных объявлений) должны иметь логическое обоснование в базе данных. Если регулятор запросит, почему товар А стоит выше товара Б, вы должны иметь возможность выгрузить логические условия, которые привели к такому результаду. Без этого архитектура считается несовершенной.

Ошибки KYC и проверки партнеров через ЕГРЮЛ

С октября 2026 года маркетплейс обязан проверять партнеров через государственные информационные системы до момента заключения договора. Это не просто "загрузка скана документа", а автоматизированный процесс валидации. Ошибка проектирования здесь заключается в хранении статуса "Проверен" как булева переменной (true/false) без привязки к дате и источнику данных.

Партнер может быть активен сегодня, но завтра его компания будет ликвидирована или попадет в реестр недобросовестных поставщиков. Если ваша база данных не предусматривает периодический ре-чек (re-verification) данных из ЕГРЮЛ/ЕГРИП, вы нарушаете требования закона. Архитектура должна поддерживать механизм автоматического триггера: при изменении статуса компании в госреестрах, статус партнера в вашей системе должен автоматически переходить в состояние "Suspended" (приостановлен) до повторной проверки.

Как правильно реализовать KYC-модуль

Вместо хранения статичных данных о компании, используйте событийную модель:

1. Создается запись о первичной проверке (Timestamp, ID записи в ЕГРЮЛ, результат запроса к API ФНС).
2. Настраивается расписание автоматических запросов (например, раз в 30 дней).
3. Любое несоответствие (изменение директора, юридического адреса, статуса ликвидации) генерирует системное событие для модератора.

Типичная ошибка - отсутствие истории изменений юридических данных партнера. Если селлер совершил мошенническую операцию, вам нужно точно знать, какой статус его юридического лица был на момент совершения транзакции. Хранить только "текущее состояние" нельзя - это делает невозможным проведение аудита и защиту в суде.

Проблемы версионирования оферт и уведомлений селлеров

Закон 289-ФЗ установил жесткие сроки для коммуникаций. Теперь вы обязаны предупреждать партнера об ухудшении условий договора за 45 дней, а о санкциях - за 3 дня. Если ваша база данных хранит только последнюю версию оферты, вы обречены на штрафы. Каждое изменение правил - это новая версия документа, которая должна быть связана с конкретным периодом действия.

Проблема версионирования часто упирается в то, как организована связь между договором и уведомлениями. Нельзя просто отправить Push-уведомление. В БД должна существовать таблица "Журнал уведомлений", где зафиксировано: текст сообщения, время доставки, факт прочтения (или статус "прочитано через N дней") и версия оферты, к которой относится это уведомление. Это критически важно, так как юридическим фактом считается не факт отправки, а факт предоставления возможности ознакомиться.

Сравнение подходов к хранению оферт

При проектировании важно учитывать "эффект наложения". Если вы меняете условия на 45 дней вперед, система должна позволять селлеру работать по старым правилам в этот период, но автоматически переключать его на новые условия в назначенный день. Это требует сложной логики в модуле биллинга и расчета комиссий, чтобы не возникло перекосов в расчетах за прошедший период.

Хранение истории скидок и протоколов согласий

Одна из самых коварных зон - механизм снижения цены за счет продавца. Согласно новым нормам, для этого требуется письменное согласие партнера. При этом уведомление о планируемой скидке должно приходить минимум за 5 рабочих дней. Ошибка в проектировании здесь - использование простых флагов "скидка включена".

Вам нужна модель "Предложение - Согласие - Активпость". Сначала создается запись о предложении (предварительная скидка, сроки действия, размер). Затем - запись о согласии селлера (ID пользователя, Timestamp, версия оферты, в которой прописано право на такие изменения). Только после этого скидка становится активной в прайс-листе. Если вы просто меняете цену в таблице `products`, вы теряете доказательную базу для защиты от претензий селлеров.

Также важно хранить протоколы согласий на участие в промоакциях. Часто селлеры жалуются: "Я не разрешал снижать цену до такого уровня". Если в вашей БД нет истории того, на какие именно условия (максимальный порог цены, период) нажал селлер, вы не сможете оспорить претензию в регуляторе. Данные должны храниться в неизменяемом виде (Immutable) с привязкой к ID сессии и IP-адресу пользователя.

Масштабирование справочников и валидация карточек товаров

С 1 октября 2026 года за ошибки в карточках товаров введены серьезные штрафы: до 70 тыс. рублей за первое нарушение, до 200 тыс. рублей за повторное. Это превращает модуль управления контентом из "простого редактора" в критически важный узел контроля рисков. Масштабирование базы данных товаров (scaling) должно учитывать не только количество позиций, но и глубину атрибутивного состава.

Типичная ошибка - создание плоской структуры атрибутов. Когда товаров становятся миллионы, попытка хранить все характеристики в одной таблице `product_attributes` приводит к катастрофическому замедлению запросов. Необходимо использовать EAV-модель (Entity-Attribute-Value) или специализированные NoSQL решения для атрибутов, но с жесткой валидацией на уровне приложения.

Алгоритм валидации контента

Чтобы избежать штрафов, процесс модерации должен выглядеть так:

1. Загрузка контента -> 2. Проверка на соответствие Постановлению Правительства № 821 (обязательные поля, достоверность) -> 3. Валидация на наличие запрещенных слов/условий -> 4. Фиксация статуса модерации в БД.

Важно понимать, что проверка должна быть автоматизированной. Человек не может проверить миллион карточек. Поэтому архитектура должна поддерживать "рейтинг достоверности" карточки. Если у товара много жалоб от пользователей или он не прошел автоматический чеклист по Постановлению № 821, система должна автоматически понижать его в выдаче или скрывать до ручной проверки, чтобы минимизировать риски штрафов для платформы.

Обеспечение неизменяемости журналов электронного документооборота

Маркетплейс обязан обеспечить бесперебойный и стандартизированный электронный обмен документами с продавцами. Это означает, что ваш модуль ЭДО (электронного документооборота) должен быть интегрирован в ядро системы на уровне транзакций. Ошибка проектирования - хранение документов в виде обычных файлов в S3-хранилище без контрольных сумм (hashes) в основной базе данных.

Если селлер утверждает, что акт сверки был изменен, вы должны иметь возможность доказать обратное. Для этого используется механизм Append-only logs. Записи в таблице документов не должны удаляться или редактироваться. Любое исправление - это создание новой записи с указанием связи с предыдущей (Chain of Custody). Это превращает журнал событий в подобие легкого блокчейна, что крайне важно при судебных разбирательствах.

Не забывайте про стандартизацию. Данные из БД должны легко конвертироваться в форматы, поддерживаемые государственными системами. Если ваша внутренняя модель данных слишком специфична и не позволяет выгрузить корректный XML/JSON файл по стандарту, это создаст операционный хаос при масштабировании бизнеса.

Риски блокировок и логирование доступа партнеров

За необоснованное ограничение доступа к личному кабинету партнера предусмотрен штраф до 500 тыс. рублей. Это делает модуль модерации и антифрода одной из самых опасных зон. Ошибка проектирования здесь - "черный ящик". Если система заблокировала селлера, у вас должен быть четкий, логически обоснованный след в базе данных: какой триггер сработал, какие данные нарушили правила, кто из модераторов подтвердил решение.

Логирование должно быть разделено на два типа: системное (технические события) и аудиторское (бизнес-события). Для аудиторского лога крайне важно хранить не только "что произошло", но и "на основании чего". Например: "Доступ ограничен. Причина: нарушение условий оферты (п. 4.2). Документ-основание: ID_Report_123". Без такой детализации любая проверка регулятора превратится в борьбу с последствиями.

Типичные ошибки в управлении доступом

Часто разработчики допускают следующие промахи:

• Отсутствие логирования действий модераторов (кто именно нажал кнопку "заблокировать").
• Невозможность восстановить состояние прав доступа на конкретную дату (нужно знать, какие права были у селлера в момент совершения транзакции).
• Отсутствие механизма "мягкого удаления" (Soft Delete) - при блокировке аккаунт не должен исчезать из базы, он должен менять статус, чтобы сохранялась вся история взаимодействий.

Безопасность персональных данных по 152-ФЗ

Несмотря на появление 289-ФЗ, Федеральный закон № 152-ФЗ остается базовым. Архитектура базы данных должна строиться на принципах минимизации данных (Data Minimization). Не храните в основной таблице `users` всё подряд. Личные данные (паспорт, ИНН, телефон) должны храниться в отдельных, максимально защищенных таблицах с ограниченным уровнем доступа.

Ключевая ошибка - отсутствие механизмов автоматического удаления (data retention policy). Если пользователь удалил аккаунт, вы обязаны удалить его персональные данные, за исключением тех, которые вы обязаны хранить по закону (например, данные о сделках для налоговой отчетности). В БД должна быть реализована логика: "Удалить персональные данные, но сохранить финансовую историю, обезличив её".

Важно также реализовать механизм контроля доступа (RBAC/ABAC) на уровне БД. Даже администратор базы данных не должен иметь возможности просто так просмотреть паспортные данные селлера без создания соответствующего события в журнале аудита. Безопасность данных в 2026 году - это не только шифрование, это прежде всего прозрачность и контролируемость каждого действия с информацией.

Что запомнить

• Проектируйте БД с учетом 289-ФЗ: статус платформы, версионирование оферт и история уведомлений - это база.
• Никаких "простых" статусов: используйте событийную модель для KYC и проверок контрагентов.
• Избегайте штрафов: внедряйте автоматическую валидацию карточек товаров по Постановлению № 821.
• Обеспечьте неизменяемость (Immutable) журналов документов и действий модераторов.
• Соблюдайте 152-ФЗ через разделение данных и автоматическое управление жизненным циклом информации.