Когда каталог перерастает CMS: признаки и что делать

Витрина открывается, товары листаются, поиск работает. А импорт прайсов падает или висит часами, утягивая за собой весь сайт. Если это про вас, дело не в мощности сервера: каталог перерос архитектуру, в которой CMS одновременно и витрина, и обработчик данных.

Как это выглядит со стороны

Симптомы узнаваемые. Загрузка каталога из файла поставщика занимает часы вместо минут. Во время импорта сайт отвечает медленно или не отвечает совсем. Один кривой файл ломает всю выгрузку, и товары на витрине остаются вчерашними. Контент-менеджеры правят карточки руками, потому что автоматика не справляется с форматами поставщиков.

Обычно в этот момент покупают сервер мощнее. Помогает на несколько месяцев, после чего всё повторяется, потому что проблема не в ресурсах.

Почему мощность не спасает

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

Дальше количество переходит в качество. Критичен не сам объём товаров, а комбинация: много позиций, много источников и у каждого свой набор свойств. Двести поставщиков с разными названиями одного и того же «диаметра» превращают каталог в зоопарк характеристик, который не вычистить правилами на стороне сайта.

Что помогает на самом деле

Развести обработку и витрину по разным контурам. Данные от поставщиков принимает и приводит в порядок отдельная система на отдельном сервере, а на сайт попадает уже готовый результат. Пиковая нагрузка на импорте физически не может уронить витрину, потому что они больше не соседи.

Такая система называется PIM. Её работа — принять любой формат, сопоставить поля поставщика с полями каталога по заданным правилам, нормализовать единицы измерения и валюты, собрать разнородные свойства в управляемый справочник атрибутов. Дальше сайт забирает изменения по расписанию.

Три вещи в этой схеме решают больше остального:

Загрузка дельтами. Забираются только изменения, а не весь каталог каждый раз. Именно полная перезагрузка обычно и кладёт сервер.

Обработка ошибок построчно. Битая строка логируется и не публикуется, остальные товары проходят. Один плохой файл перестаёт быть катастрофой.

Разделение доступов. Контент-менеджеры работают в PIM, а не в административной части сайта. Сломать витрину неосторожной правкой становится невозможно, и доступ в админку остаётся у одного человека.

Чего это стоит в цифрах

В проекте для торгового комплекса «Тандем» мы перенесли на эту схему каталог из 250 000 позиций от 200 с лишним арендаторов. Команда контент-менеджеров тратила на обработку товарных данных до ста часов в неделю, то есть полторы ставки уходило на копирование. После перехода осталось около двух часов в неделю на контроль. Обновление цен сократилось с нескольких дней до десяти минут от файла поставщика до витрины.

Отдельно про надёжность: изображения вынесли в объектное хранилище, чтобы не платить за гигабайты картинок на быстром диске сервера, и зафиксировали показатели восстановления — сутки максимальной потери данных и четыре часа до полного возврата сервиса. Это цифры в договорённостях, а не обещание постараться.

Подробный разбор с архитектурой, стеком и этапами — в кейсе 250 000 SKU от 200+ арендаторов. Там же история о том, как первая версия каталога, которую мы делали сами, перестала справляться, и почему вторую спроектировали иначе.

Когда PIM не нужен

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

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

С чего начать, если симптомы знакомы

Сначала измерить: сколько времени занимает импорт, в какие часы он идёт, что происходит с откликом сайта в это время, сколько часов в неделю уходит на ручные правки. Без этих чисел любое решение будет угадыванием, а разговор с подрядчиком — спором о вкусах.

Дальше решать, что именно перегружено: сервер, структура каталога или сама схема обмена. Мы разбираем это техническим аудитом сайта, а саму перестройку обмена закрываем интеграцией с внешними системами. Если каталог пока держится, но сайт стал медленным по другим причинам, начните с инструкции что проверить, когда сайт тормозит.