Архитектура e-commerce-платформы: как связать каталог, заказы, оплату и логистику

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

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

Каталог может жить в ERP, остатки — в складской системе, цены — в отдельном сервисе, а заказ — в e-commerce-контуре. Для каждого объекта нужно явно указать владельца и правила синхронизации.

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

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

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

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

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

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

Логи должны объяснять, где остановился заказ, но не хранить платёжные секреты и лишние персональные данные. Это одновременно вопрос поддержки и безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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