Как разработать e-commerce в 2026 году

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

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

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

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

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

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

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

2. Выбрать платформу под ближайшие изменения бизнеса

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

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

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

3. Договориться, какая система отвечает за каждый тип данных

Фраза «всё приходит из 1С» часто скрывает несколько разных процессов. Учётная система может хранить номенклатуру и цены, складская — физический остаток, а система управления заказами — резерв и количество, доступное к продаже.

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

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

4. Построить общую серверную часть для каналов продаж

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

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

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

Как может выглядеть технологическая основа

Один из вариантов для заказной платформы — Python и FastAPI на сервере, PostgreSQL для данных приложения, React и Next.js для сайта, Flutter для мобильного приложения. Redis может выполнять роль кэша, Elasticsearch — поискового индекса, объектное хранилище и CDN — обслуживать медиа.

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

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

5. Разделить товарные данные, контент и поиск

У этих частей разные задачи и темп изменений.

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

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

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

Поисковый индекс хранит подготовленное представление каталога для поиска и фильтрации. Его можно перестроить из исходных данных. В Elasticsearch доступны механизмы синонимов и нечёткого совпадения; их нужно настраивать под каталог. Документация Elastic о синонимах и нечётком поиске.

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

Где помогает AI

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

Предположение модели о совместимости детали нельзя автоматически превращать в подтверждённое свойство товара. Коммерческие данные и технические характеристики должны сохранять прослеживаемое происхождение.

6. Сделать покупку удобной на телефоне и доступной для поиска

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

Для публичных страниц каталога стоит предусмотреть серверный или предварительный рендеринг основного содержимого. Google рекомендует рассматривать эти подходы, поскольку они полезны для скорости, а не все поисковые роботы выполняют JavaScript. Это не заменяет работу над ссылками, адресами и индексируемостью. Рекомендации Google по JavaScript SEO.

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

Кэшировать с учётом характера данных

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

Для нескольких экземпляров Next.js потребуется согласовать кэш и его сброс. Общее хранилище, например Redis, — один из вариантов; оно подключается через соответствующий обработчик. Архитектура должна учитывать используемые механизмы и версию Next.js. Руководство Next.js по самостоятельному размещению.

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

7. Спроектировать интеграции вместе со сценариями отказа

Обмен с 1С, оплатой и доставкой — часть поведения магазина. Нужно заранее решить, что покупатель увидит, если внешняя система отвечает медленно или недоступна.

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

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

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

8. Проверить перенос данных до финального запуска

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

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

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

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

Подробная последовательность разобрана в статье о переносе интернет-магазина с 1С-Битрикс.

9. Принимать систему по нагрузке и восстановлению

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

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

Наблюдать за продажами, а не только за серверами

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

Восстановление должно быть проверено

Согласуйте две бизнес-величины: допустимую потерю данных по времени — RPO — и допустимое время восстановления — RTO. Их значения определяют требования к резервным копиям, репликам и переключению. Универсального целевого времени для всех магазинов нет.

Для PostgreSQL восстановление на точку времени строится на базовой резервной копии и непрерывном архиве журнала WAL. Копии необходимо хранить вне основного сервера базы. Документация PostgreSQL о PITR.

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

10. Подготовить основу для следующих изменений

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

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

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

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

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