В 2025 году маркетплейсы всё активнее поглощают классический eCommerce. Хотя вроде уже и нет.  Пока неясно, выживет ли традиционный формат интернет-магазинов. Наверное да, но это не точно.

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

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

Стартовый этап: готовое решение

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

Рассмотрим эволюционный путь, который сложился в нашей практике. Сразу пропустим Tilda и прочие SaaS-решения — у них нет точек масштабирования. Мы с клиентом смотрим дальше, насколько это возможно в современных реалиях.

Начинаем с комбинации Битрикс + готовое решение. Можете критиковать, но качественно собранное готовое решение, поддающееся кастомизации, для старта вполне приемлемо. Особенно если учесть, что в него вложено около 1000 часов разработки, и маловероятно, что на стадии MVP вы создадите нечто подобное.

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

Развитие и первые ограничения

Проект запущен и работает. Интеграции сделаны и проверены, данные перемещаются без сбоев. Что дальше?

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

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

Модернизация фронтенда

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

Решение: разрабатываем API. На базе текущего бэкенда создаём API для Битрикса, мы обычно используем микрофреймворк Slim — как-нибудь напишу об этом отдельно. Параллельно разрабатываем отдельный фронтенд — веб, мобильное приложение или что угодно другое. Связываем всё, и вуаля — у нас свой фронтенд, который можно развивать отдельной командой и который лучше справляется с нагрузкой.

Модернизация бэкенда

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

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

В результате получается своего рода «Франкенштейн»: фронтенд — отдельное приложение, API работает через Битрикс, а к нему подключена куча сервисов.

Полная модернизация

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

В итоге мы получаем полноценную микросервисную систему с хорошим фронтендом и быстрым бэкендом.

Заключение

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

Описанный путь применим как для B2B, так и для B2C, и для любого коробочного решения — Битрикс использован лишь в качестве примера. Вы можете взять любую другую CMS и повторить этот подход.

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