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

П'ятдесят тисяч товарів на восьми ринках, це не великий магазин. Це інша система.

Бізнес із тисячею товарів в одній країні і бізнес із п'ятдесятьма тисячами товарів у восьми країнах не роблять одне й те саме в різних обсягах.

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

Цю відмінність зазвичай виявляють, а не планують. Каталог росте, додається ринок, потім ще один, і в якийсь момент платформа, яка справлялась з усім спокійно, починає поводитись дивно. Сторінки сповільнюються. Імпорт, що займав хвилини, іде годинами. Оновлення ціни на одному ринку проявляється на іншому. Ніхто не може сказати, коли саме це змінилось, бо це не змінювалось у жоден окремий момент.

Масштаб рідко оголошує про себе. Він накопичується, поки не зламається щось видиме.

Причина вужча, ніж здається, і її варто назвати раніше за все інше.

Масштаб робить e-commerce складнішим не тому, що товарів більше. Він робить його складнішим тому, що кожен товар існує у більшій кількості станів, і ці стани мають лишатись узгодженими.

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

Множення, а не додавання

Множення, а не додавання

Інстинкт підказує трактувати розмір каталогу і кількість ринків як дві окремі задачі, які можна вирішити послідовно.

Це одна задача, і зв'язок між її частинами множинний.

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

На п'ятдесяти тисячах товарів це не більша база даних. Це інша категорія системи, бо кількість речей, здатних тихо розійтись одна з одною, зросла на два порядки.

Робота більше не у зберіганні інформації. Вона у підтриманні узгодженості станів.

Саме тут вибір платформи перестає бути цікавим питанням. Будь-яка серйозна платформа втримає п'ятдесят тисяч записів. Питання в тому, що відбувається, коли ці записи мають узгоджуватись одне з одним через ринки, валюти і юрисдикції.

Розділи далі, це та сама задача під різними кутами. Кожен, це вимір, за яким стан товару може розійтись, і кожен потрібно вирішити, а не успадкувати.

Ціна перестає бути полем

Ціна перестає бути полем

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

На восьми ринках вона стає обчисленням, і вхідні дані лежать не в одному місці.

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

Далі питання, хто перемагає, коли застосовні два правила одразу, а це бізнес-рішення, яке потрібно ухвалити до того, як його можна закодувати.

Ціна стає обчислюваним значенням із заданим порядком пріоритетів, а не полем, яке хтось редагує.

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

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

Залишок, це не число

Залишок, це не число

Складський облік слідує тому самому патерну і прощає менше, бо збій видно клієнту.

Один склад, що обслуговує вісім ринків, і вісім складів, що обслуговують вісім ринків, це різні системи, а більшість бізнесів на цьому масштабі перебувають десь між.

Питання, на які потрібно відповісти, операційні, а не технічні. Що показувати, коли товар є в Польщі і немає в Іспанії, а іспанський клієнт погодився б на довшу доставку? Коли резервується залишок, при оформленні чи при оплаті, і як довго тримається? Що відбувається, коли два ринки продають останню одиницю в ту саму хвилину?

У жодного з цих питань немає відповіді за замовчуванням, і кожне змінює архітектуру.

Пересорт, це не баг, що з'являється на масштабі. Це те, що відбувається, коли модель резервування не була явно вирішена.

Другий вимір, і перший, де неузгоджений стан стає проблемою клієнта, а не внутрішньою.

Податки, це архітектура

Податки, це архітектура

На восьми ринках податок перестає бути чимось, що застосовується при оформленні замовлення.

Ставки різняться за країнами і часто за товарними категоріями всередині країни. Пороги визначають, коли бізнес зобов'язаний зареєструватись на ринку, куди продає. B2B і B2C трактуються по-різному, іноді вимагаючи перевірки податкового номера клієнта, перш ніж коректну ставку взагалі можна застосувати. Ціни на одних ринках показуються з податком, на інших без, і це змінює те, що клієнт бачить ще до будь-яких розрахунків.

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

Це невидимо на вітрині і неминуче в розробці. І це не можна додати пізніше, не зачепивши модель ціноутворення, бо податкова трактовка і відображення ціни, це одне рішення, побачене з двох боків.

Третій вимір, і перший, де в неузгодженого стану з'являється юридичний наслідок, а не комерційний.

П'ятдесят тисяч описів

П'ятдесят тисяч описів

Задача локалізації на цьому масштабі, це не бюджет на переклад. Це виробничий процес, який має йти безперервно.

П'ятдесят тисяч товарів на восьми ринках, це чотириста тисяч станів, які потрібно написати, перевірити і підтримувати в актуальності.

50 000 товарів на 8 ринках, це 400 000 станів.

Ця цифра, це множення, зроблене видимим, і саме тому локалізація на такому масштабі поводиться інакше, ніж локалізація невеликого сайту. Каталог не стоїть на місці, поки ці стани виробляються. Товари додаються, знімаються, переоцінюються і перекласифіковуються щодня, а отже це не мета, яку досягають, а обсяг, який підтримують.

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

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

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

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

Пошук ламається першим

Пошук ламається першим

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

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

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

Рішення пошуку на цьому масштабі додає ще один стан на товар, а не прибирає.

Пошук перестає бути функцією платформи. Він стає компонентом.

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

Імпорт стає інфраструктурою

Імпорт стає інфраструктурою

На маленькому каталозі імпорт товарів, це задача. На п'ятдесяти тисячах позицій, що оновлюються щодня, це система зі своїми режимами відмови.

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

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

Тому системі потрібен зазор між отриманням даних і публікацією: перевірка до запису, зміни, підготовлені до застосування, а не застосовані, і шлях назад, коли щось усе ж пройшло.

Але рішення, яке важливіше за все, простіше за будь-яке з перелічених. Це де живе джерело істини.

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

Сигнали теж множаться

Сигнали теж множаться

Пошуковий шар, звернений назовні, множиться так само, як звернений усередину.

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

Це генерована інфраструктура, а не робота з контентом. Згенерована вірно, вона невидима. Згенерована із системною помилкою, ця помилка присутня одразу на кожному товарі, і збій при цьому тихий.

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

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

Що ламається першим насправді

Що ламається першим насправді

Бізнеси на цьому масштабі зазвичай чекають, що крихкою частиною виявиться вітрина. Вона рідко нею виявляється.

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

Саме там помирає якість даних, і саме це невидимо при будь-якому технічному аудиті, бо в коді нічого не зламано.

Каталог не став некерованим. Некерованими стали інструменти для нього.

Операційній стороні на цьому масштабі потрібне інше за своєю природою: масове редагування з перевіркою, зміни, підготовлені і переглянуті до публікації, ясний запис про те, що і ким змінено, і можливість відкотити погане оновлення без відновлення з резервної копії.

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

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

Рішення до коду

Рішення до коду

Усе вищеописане, це наслідок рішень, які дешево ухвалити рано і дорого переглядати.

Де дані про товари авторитетні і що відбувається, коли дві системи розходяться. Зберігається ціна по ринках чи виводиться, і яке правило перемагає, коли застосовні кілька. Як моделюється залишок по складах і ринках і коли він резервується. Які ринки ділять контент, а яким потрібен свій. Як каталог має виглядати через три роки, бо модель, що підходить п'ятдесяти тисячам товарів, може не пережити двохсот тисяч.

Ніщо з цього не деталі реалізації. Це архітектура, і вона вирішується до першого осмисленого рядка коду, тому фаза discovery на такому проєкті довша, ніж очікують клієнти, і дешевша за альтернативу.

На цьому масштабі дорогі помилки скоюються в перший місяць.

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

Архітектура не створює проблему на масштабі. Вона визначає, яка частина проблеми автоматична, а яка ручна.

Зв'язок між складністю каталогу і вартістю розробки викладено у статті Що насправді робить розробку e-commerce дорогою, а наслідки хибних структурних рішень у статті Прихована ціна хибної архітектури.

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