Мультистрановый e-commerce для больших каталогов: архитектурные решения, задающие потолок

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

Бизнес с тысячей товаров в одной стране и бизнес с пятьюдесятью тысячами товаров в восьми странах не делают одно и то же в разных объёмах.

Второй решает распределённую задачу по данным, к которой прилагается витрина.

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

Масштаб редко объявляет о себе. Он накапливается, пока не сломается что-то видимое.

Причина уже, чем кажется, и её стоит назвать раньше всего остального.

Масштаб делает e-commerce сложнее не потому, что товаров больше. Он делает его сложнее потому, что каждый товар существует в большем количестве состояний, и эти состояния должны оставаться согласованными.

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

Умножение, а не сложение

Умножение, а не сложение

Инстинкт подсказывает трактовать размер каталога и количество рынков как две отдельные задачи, которые можно решить последовательно.

Это одна задача, и связь между её частями умножающая.

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

На пятидесяти тысячах товаров это не более крупная база данных. Это другая категория системы, потому что количество вещей, способных тихо разойтись друг с другом, выросло на два порядка.

Работа больше не в хранении информации. Она в поддержании согласованности состояний.

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

Главы дальше, это та же задача под разными углами. Каждая, это измерение, по которому состояние товара может разойтись, и каждое нужно решить, а не унаследовать.

Цена перестаёт быть полем

Цена перестаёт быть полем

В магазине на одном рынке цена, это число, прикреплённое к товару.

На восьми рынках она становится вычислением, и входные данные лежат не в одном месте.

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

Дальше вопрос, кто побеждает, когда применимы два правила сразу, а это бизнес-решение, которое нужно принять до того, как его можно закодировать.

Цена становится вычисляемым значением с заданным порядком приоритетов, а не полем, которое кто-то редактирует.

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

Это первое измерение. Хранятся эти восемь значений отдельно или выводятся из правила, каждое должно быть верным на своём рынке, и модель решает, какую из двух задач бизнес обслуживает.

Остаток, это не число

Остаток, это не число

Складской учёт следует тому же паттерну и прощает меньше, потому что сбой виден клиенту.

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

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

Ни у одного из этих вопросов нет ответа по умолчанию, и каждый меняет архитектуру.

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

Второе измерение, и первое, где несогласованное состояние становится проблемой клиента, а не внутренней.

Налоги, это архитектура

Налоги, это архитектура

На восьми рынках налог перестаёт быть чем-то, что применяется при оформлении заказа.

Ставки различаются по странам и часто по товарным категориям внутри страны. Пороги определяют, когда бизнес обязан зарегистрироваться на рынке, куда продаёт. B2B и B2C трактуются по-разному, иногда требуя проверки налогового номера клиента, прежде чем корректную ставку вообще можно применить. Цены на одних рынках показываются с налогом, на других без, и это меняет то, что клиент видит ещё до всяких расчётов.

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

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

Третье измерение, и первое, где у несогласованного состояния появляется юридическое последствие, а не коммерческое.

Пятьдесят тысяч описаний

Пятьдесят тысяч описаний

Задача локализации на этом масштабе, это не бюджет на перевод. Это производственный процесс, который должен идти непрерывно.

Пятьдесят тысяч товаров на восьми рынках, это четыреста тысяч состояний, которые нужно написать, проверить и поддерживать в актуальности.

50 000 товаров на 8 рынках, это 400 000 состояний.

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

Узкое место на практике редко в самом переводе. Оно между сырыми данными поставщика и публикуемой карточкой: атрибуты приходят в несогласованных форматах, характеристик не хватает, значения означают разное у разных поставщиков.

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

На этом масштабе локализация перестаёт быть проектом с датой окончания и становится операционным конвейером с пропускной способностью.

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

Поиск ломается первым

Поиск ломается первым

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

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

Стандартный ответ, это выделенный поисковый слой, и значимо здесь то, что это означает структурно. Это не оптимизация существующей системы. Это вторая копия каталога, хранимая в другой форме для другой цели, которая теперь тоже должна согласовываться с первой.

Решение поиска на этом масштабе добавляет ещё одно состояние на товар, а не убирает.

Поиск перестаёт быть функцией платформы. Он становится компонентом.

Фасетная навигация приносит вторую проблему, невидимую, пока её не измеришь. Комбинации фильтров порождают URL, и на таком размере каталога их порождается очень много, причём большинство никогда не должно попадать в индекс. Без управления краулинговый бюджет уходит на перестановки фильтров, пока страницы товаров, которые должны ранжироваться, ждут позади них.

Импорт становится инфраструктурой

Импорт становится инфраструктурой

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

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

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

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

Но решение, которое важнее всего, проще любого из перечисленного. Это где живёт источник истины.

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

Сигналы тоже умножаются

Сигналы тоже умножаются

Поисковый слой, обращённый наружу, умножается так же, как обращённый внутрь.

Восемь языковых версий пятидесяти тысяч товаров означают, что каждый товар несёт набор аннотаций, объявляющих его альтернативы, и каждый такой набор должен быть внутренне согласован. Связи взаимны, поэтому количество деклараций, которые должны совпадать, значительно и не поддерживается вручную.

Это генерируемая инфраструктура, а не работа с контентом. Сгенерированная верно, она невидима. Сгенерированная с системной ошибкой, эта ошибка присутствует сразу на каждом товаре, и сбой при этом тихий.

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

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

Что ломается первым на самом деле

Что ломается первым на самом деле

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

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

Именно там умирает качество данных, и именно это невидимо при любом техническом аудите, потому что в коде ничего не сломано.

Каталог не стал неуправляемым. Неуправляемыми стали инструменты для него.

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

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

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

Решения до кода

Решения до кода

Всё вышеописанное, это следствие решений, которые дёшево принять рано и дорого пересматривать.

Где данные о товарах авторитетны и что происходит, когда две системы расходятся. Хранится цена по рынкам или выводится, и какое правило побеждает, когда применимы несколько. Как моделируется остаток по складам и рынкам и когда он резервируется. Какие рынки делят контент, а каким нужен свой. Как каталог должен выглядеть через три года, потому что модель, подходящая пятидесяти тысячам товаров, может не пережить двухсот тысяч.

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

На этом масштабе дорогие ошибки совершаются в первый месяц.

Прочитанная назад, вся последовательность коротка. Каталог растёт и добавляет рынки. Каждый товар начинает существовать в большем числе состояний. Поддержание их согласованности становится ежедневной операционной работой. А объём этой работы был зафиксирован, прежде чем кто-либо заметил, решениями о модели данных, принятыми тогда, когда каталог был достаточно мал, чтобы они не имели значения.

Архитектура не создаёт проблему на масштабе. Она определяет, какая часть проблемы автоматическая, а какая ручная.

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

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