«API есть у всех. Почему e-commerce всё равно превращается в паутину»

Архитектура торговли #01

У продавца 21 кабинет Wildberries.

Товары в них одни и те же.

Кончился один товар — остаток нужно обнулить во всех 21 кабинетах.

На первый взгляд это обычная задача автоматизации.

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

И время оказалось даже не главной проблемой.

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

Дальше вполне материальная цепочка:

заказ → товара нет → отмена → санкции площадки.

Автор автоматизировал процесс через API Wildberries.

Казалось бы, проблема решена.

Но именно здесь начинается самое интересное.

При обращении сразу к 21 кабинету часть операций может выполниться, а часть — нет.

Поэтому система должна не просто отправить 21 запрос, а знать:

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

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

И это хороший пример того, почему современный e-commerce постепенно перестаёт быть задачей «сделать ещё одну интеграцию».

Представим компанию, которая начинает продавать онлайн.

Есть учётная система.

Есть интернет-магазин.

Появляется маркетплейс.

Архитектура выглядит примерно так:

Нужно подключить новую площадку?

Пишем ещё один коннектор.

До определённого момента такой подход отлично работает.

Потом появляется ещё одна площадка.

Потом ещё одна.

Потом выясняется, что карточками товаров удобнее управлять в PIM.

Остатки живут в WMS.

Клиенты — в CRM.

Фотографии — в DAM.

Заказы должны попадать в ERP.

Часть данных приходит от поставщиков.

И простая схема начинает выглядеть примерно так:

Где-то рядом обычно ещё находятся:

Пока этот человек не ушёл в отпуск.

В какой-то момент проблема меняется.

Вопрос уже не:

Можем ли мы вызвать API?

А:

Кто управляет взаимодействием всех этих систем?

Хороший пример есть в старом, но очень показательном кейсе Lacoste на vc.ru.

У компании интернет-магазин и розница фактически существовали как два отдельных мира.

Интернет-магазин не видел остатки розничных точек.

Розничный магазин не мог посмотреть остатки других магазинов.

У отдельных магазинов были собственные 1С.

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

Получалась интересная ситуация.

Товар физически есть в компании.

Но одна часть компании об этом не знает.

Покупатель приходит в магазин — нужного размера нет.

В соседнем магазине этот размер может лежать.

Но продавец этого не видит.

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

С точки зрения каждой отдельной системы всё нормально.

С точки зрения бизнеса — состояние раздроблено.

Когда Lacoste понадобился Click & Collect, просто добавить ещё одну интеграцию оказалось недостаточно.

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

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

Это важный момент.

Проблемой была не 1С.

Не интернет-магазин.

Не отсутствие API.

Каждый компонент выполнял свою функцию.

Проблема находилась между компонентами.

Практически любая современная commerce-платформа умеет через API:

На бумаге кажется:

Отлично. Осталось всё соединить.

Но возьмём обычный заказ.

Покупатель нажал кнопку «Купить».

Что происходит дальше?

Получили заказ ↓ Проверили его ↓ Создали внутренний заказ ↓ Зарезервировали товар ↓ Пересчитали доступный остаток ↓ Обновили остальные каналы ↓ Передали заказ в ERP ↓ Создали отгрузку ↓ Получили новый статус ↓ Передали статус обратно

Это уже не просто:

Marketplace → ERP

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

А теперь добавим маленькую деталь.

На шестом шаге одна площадка не ответила.

Что делать со всеми предыдущими шагами?

Возьмём обычную карточку товара.

В ней есть:

Название Описание Цена Остаток Фотографии Штрихкод Сертификат

Но в крупной торговой системе это вполне может храниться так:

Название → PIM Описание → PIM Цена → ERP Остаток → WMS Штрихкод → MDM Сертификат → Compliance Фотографии → DAM

Потом менеджер открывает кабинет маркетплейса.

И вручную меняет цену:

4 990 ₽ → 4 490 ₽

Проходит минута.

Система обнаруживает расхождение.

Вариант A

ERP является источником истины.

Вернуть:

4 990 ₽

Вариант B

Изменение на маркетплейсе разрешено.

Записать:

4 490 ₽

обратно в ERP.

Вариант C

Создать конфликт и попросить человека решить.

Вариант D

Цена конкретного канала вообще должна иметь право отличаться от базовой.

Все четыре варианта могут быть правильными.

Но API площадки не знает, какой вариант нужен вашему бизнесу.

API отвечает на вопрос:

Как записать цену?

Но не отвечает:

Кто имеет право её менять и какое значение считать правильным?

Это уже управление состоянием.

Представим, что правильный остаток товара:

9

Мы отправляем его в три канала.

Получаем:

Marketplace A → 9 ✅ Marketplace B → timeout ❓ Marketplace C → 9 ✅

Операция успешна?

Непонятно.

ERP говорит:

9

Marketplace A:

9

Marketplace C:

9

А Marketplace B может показывать:

10

Но timeout ещё не обязательно означает, что запрос не выполнился.

Возможно:

Если просто выполнить запрос ещё раз — нужно понимать, безопасно ли это.

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

То есть банальная операция:

«Поставить остаток 0»

на масштабе превращается примерно в:

А если каналов не 21 кабинет одного маркетплейса, а:

задача становится ещё интереснее.

Иногда она гораздо заметнее в человеко-часах.

Есть ещё один кейс на vc.ru — автоматизация работы продавца с Lamoda.

По описанию автора, до автоматизации сотрудник ежедневно тратил 3–4 часа на работу с заказами через чат-бот, Excel и дополнительный сервис.

Отдельной проблемой назывались ошибки в остатках из-за человеческого фактора.

После появления модуля 1С, связанного с API Lamoda, заказы начали загружаться автоматически, остатки синхронизироваться, а заявленное автором время обработки сократилось примерно с трёх часов до двадцати минут.

Здесь важно сделать оговорку:

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

Но сам паттерн интереснее цифр:

Заказы + Excel + этикетки + остатки + 1С + API + ручные действия

С ростом количества операций ручной процесс становится отдельной системой интеграции.

Просто вместо кода роль middleware выполняет человек.

Все современные системы становятся всё более открытыми.

У всех есть API.

Есть webhook.

Есть очереди.

Есть SDK.

Есть документация.

Но количество интеграционных проблем почему-то не стремится к нулю.

Иногда происходит наоборот.

Причина довольно проста.

API уменьшает стоимость создания одной связи.

Но с ростом бизнеса увеличивается количество связей и процессов между ними.

Если условно имеются:

ERP PIM WMS CRM Shop Marketplace 1 Marketplace 2 Marketplace 3

то нужно управлять уже не просто восемью системами.

Нужно понимать:

Именно здесь появляется интеграционный долг.

Он очень похож на технический долг старого монолита.

Только вместо запутанного кода у нас запутанные связи между системами.

Backend-разработчики уже знают многие проблемы из этого списка:

Что делать, если площадка временно недоступна?

Можно ли безопасно повторить запрос?

Как не создать два одинаковых заказа?

Что делать, если событие «заказ отменён» пришло раньше события «заказ создан»?

Что если остаток одновременно изменился на складе и из-за нового заказа?

Как обновить десятки тысяч товаров, не превысив ограничения API?

Что делать, если пять систем обновились, а шестая — нет?

Допустимо ли, что разные системы несколько минут показывают разные данные?

Куда отправлять операции, которые так и не удалось выполнить?

Как через час убедиться, что ERP, склад и каналы снова показывают согласованное состояние?

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

В commerce неправильный ответ может означать:

Когда появляется новая площадка, почти всегда спрашивают:

Как интегрировать ещё один маркетплейс?

Для небольшой инфраструктуры это правильный вопрос.

Но после определённого масштаба полезнее спросить иначе:

Как управлять всеми commerce-системами и их состоянием как одним целым?

Потому что это две разные задачи.

Как передать данные из A в B?

Что должно произойти во всей системе после изменения состояния?

Например:

Это уже не задача одного коннектора.

Lacoste: интернет-магазин, розничная сеть, несколько 1С и разрозненные остатки.

Продавец Wildberries: 21 кабинет, одни товары, API, очередь, rate limit и частичные сбои.

Продавец Lamoda: 1С, API, остатки, заказы и часы ручной работы между системами.

Масштаб разный.

Технологии разные.

Годы разные.

Но архитектурная проблема похожа:

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

Именно отсюда мы подходим к понятию Commerce Orchestration.

Не как к очередному модному названию интеграционной платформы.

А как к попытке ответить на вопрос:

Кто должен управлять состоянием и бизнес-процессами распределённой торговой системы?

Об этом — в следующей части.

А как это устроено у вас?

Если одновременно работают 1С/ERP, склад и несколько каналов продаж:

где находится источник истины по цене и остаткам?

И ещё интереснее:

что происходит, когда один из каналов не принимает обновление?