Разработка e-commerce платформы: архитектура и интеграции
Как спроектировать e-commerce платформу так, чтобы она выдерживала рост ассортимента, новые каналы продаж и интеграции с учётными системами.
26 июля 2026 · 7 мин чтения · Александр Меретти
Архитектура e-commerce платформы отличается от архитектуры обычного сайта одним требованием: она должна выдерживать рост ассортимента, новые каналы продаж и постоянный обмен данными с учётными системами без остановки продаж на время доработок. Разбираем, из каких компонентов складывается такая платформа, какие интеграции для неё обязательны и во сколько обходится разработка на разных уровнях сложности.
Бизнес-контекст выбора архитектуры
Хорошая архитектура строится вокруг данных, а не вокруг экранов. В основе — модель товара, цены и остатка, к которой обращаются все остальные модули: витрина, кабинет, интеграции и отчётность. Если эта модель спроектирована как единый источник правды, добавление нового канала продаж не требует переписывания логики — достаточно подключить его к существующему API.
- Каталог-сервис — товары, категории, характеристики, версии карточек
- Прайсинг — базовые и контрактные цены, скидки, правила для сегментов клиентов
- Остатки — резервирование, синхронизация между складами и каналами
- Заказы — жизненный цикл заказа от оформления до закрытия
- Оплата — интеграция с эквайрингом и обработка статусов платежа
- Доставка — расчёт стоимости и сроков, передача в курьерские службы
- Аналитика — сквозные отчёты по каналам, воронке и повторным покупкам
Мы проектируем такую архитектуру в разработке e-commerce платформ начиная с модели данных и только затем — с экранов: это снижает риск того, что интерфейс придётся переделывать при добавлении нового канала продаж или ценовой политики.
Trade-offs: скорость vs гибкость
Практически ни одна e-commerce платформа не работает в изоляции — вокруг неё выстраивается контур из нескольких обязательных сервисов.
| Сервис | Роль в платформе |
|---|---|
| 1С | Синхронизация каталога, остатков и заказов между витриной и учётной системой в обе стороны |
| МойСклад | Складской учёт и резервирование товара синхронно с заказами на витрине |
| ЮKassa | Приём оплаты картой, через СБП и в рассрочку со статусом сразу после оплаты |
| СДЭК | Расчёт стоимости и сроков доставки прямо в корзине, до оформления заказа |
| RetailCRM | Передача заказов менеджерам для обработки и повторных продаж по базе клиентов |
| CDP | Единый профиль покупателя из данных сайта, заказов и рассылок для персонализации |
Главный риск на этапе интеграций — не техническая сложность подключения, а отсутствие явного определения master-данных: если непонятно, какая система считается источником правды по остатку, платформа рано или поздно покажет покупателю товар, которого физически уже нет на складе.
Когда хватает простого контура
Процесс разработки e-commerce платформы проходит через шесть последовательных этапов: погружение в ассортимент и каналы продаж (1–2 недели), проектирование каталога, цен, остатков и интеграций с доставкой (1–3 недели), дизайн витрины с проверкой пути до заказа в прототипе (2–4 недели), разработка спринтами с еженедельной демонстрацией рабочей витрины (3–16 недель), запуск с тестированием оплаты и доставки, переносом каталога и обучением команды (1–2 недели), и развитие после запуска — отслеживание конверсии заказов и добавление новых каналов.
Когда нужна более сложная схема
Бюджет e-commerce платформы обычно раскладывается на три уровня в зависимости от глубины интеграций и объёма аналитики.
| Уровень | Бюджет | Срок | Что входит |
|---|---|---|---|
| Основа | от 360 000 ₽ | 8–12 недель | Ключевой сценарий роста цифровых продаж, UX-прототип, адаптивная разработка, тестирование перед запуском |
| Рост | от 570 000 ₽ | 12–18 недель | Всё из «Основы» + интеграции с сервисами, расширенная аналитика, подготовка команды клиента |
| Масштаб | от 960 000 ₽ | 18–28 недель | Всё из «Роста» + нагрузочное тестирование, роли и безопасность, план развития продукта |
Итоговая оценка зависит от количества интеграций и объёма переносимых данных — состав работ фиксируется до старта, чтобы смета на этапе подключения 1С не выросла неожиданно для заказчика.
Как мигрировать без простоя
Большинство проблем e-commerce платформ проявляется не в первый месяц, а когда бизнес пытается добавить второй канал продаж или новую ценовую политику поверх архитектуры, спроектированной под один сценарий.
- Цена и остаток хранятся отдельно для каждого канала продаж вместо единого источника данных
- Каталог спроектирован под один тип товаров и не выдерживает вариативных характеристик
- Интеграция с 1С реализована в одну сторону, без обработки конфликтов при одновременном изменении данных
- Нет версионирования цен — сложно объяснить клиенту, почему стоимость изменилась после оформления
- Аналитика собирается вручную из разных систем вместо сквозного сбора событий на платформе
Практический вывод
Перенос каталога на новую платформу — операция с прямым влиянием на органический трафик, если не подготовить её заранее. Нужна инвентаризация текущих URL карточек и категорий, карта 301-редиректов на новые адреса, сохранение индексируемых страниц с трафиком и контроль over-индексации параметров фильтров. Миграция без карты редиректов почти гарантированно приводит к падению позиций в первые недели после запуска — это стоит закладывать в план как отдельный этап, а не как побочную задачу.
Частые вопросы
С чего начинается проектирование архитектуры e-commerce платформы?
С модели данных, а не с макетов: сначала описывают, как устроены товар, цена и остаток и кто является источником правды по каждому из них. Только после этого проектируют витрину и кабинет — иначе интерфейс придётся переделывать при первой же интеграции с учётной системой.
Обязательна ли интеграция с 1С с первого дня?
Не всегда. Если 1С уже ведёт остатки и заказы, интеграцию логично закладывать сразу. Если учётная система ещё не отлажена, иногда выгоднее запустить продажи на упрощённом контуре и подключить обмен данными вторым этапом, определив заранее, где будут храниться корректные цены и остатки.
Сколько стоит разработка e-commerce платформы?
Ориентир — от 360 000 ₽ за базовый уровень с одним ключевым сценарием и сроком 8–12 недель до 960 000 ₽ и более за уровень с расширенной аналитикой, ролями и нагрузочным тестированием на сроке 18–28 недель. Итоговая цифра зависит от количества интеграций и объёма переносимых данных.
Что важнее на старте — дизайн витрины или интеграции?
Для продаж критичны оба направления, но порядок такой: сначала данные и заказной поток — остатки, оплата, статусы, — параллельно с карточкой и листингом, которые отвечают за конверсию. Красивый интерфейс с некорректным остатком теряет деньги быстрее, чем неидеальная визуальная деталь.
Как выбрать между готовой платформой и кастомной разработкой?
Готовая платформа быстрее закрывает типовые сценарии — каталог, корзина, оплата. Кастомная разработка оправдана, когда нужны нетиповая ценовая политика, сложные роли или глубокая интеграция с несколькими учётными системами. Решение стоит принимать по TCO на горизонте 12–24 месяцев, а не только по стартовой цене.
Как не потерять органический трафик при переезде на новую платформу?
Нужны инвентаризация текущих URL, карта 301-редиректов, сохранение индексируемых карточек и контроль индексации параметров фильтров. Без этой подготовки миграция каталога почти всегда приводит к временной просадке позиций в поиске сразу после запуска.
Спланируем
e-commerce платформу вместе.
На первой встрече разберём ассортимент и каналы продаж, риски и состав первой версии.