Я Максим, веб-разработчик. За последние пару лет запросы клиентов заметно изменились. Раньше владелец интернет-магазина говорил: «Сделайте мне на Битриксе». Сейчас всё чаще звучит: «Мы переросли нашу CMS, хотим собрать магазин из отдельных сервисов». Это и есть composable commerce — подход, при котором интернет-магазин строится из независимых компонентов, как конструктор. Разберёмся, кому это реально нужно, а кому навредит.

Что такое composable commerce и откуда он взялся

Классический подход к созданию интернет-магазина — монолитная платформа. Битрикс, OpenCart, WooCommerce, InSales — всё в одном пакете: каталог, корзина, оплата, доставка, личный кабинет, CMS для контента. Поставил, настроил, работает. Для большинства задач этого достаточно.

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

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

MACH-архитектура: четыре принципа

За composable commerce стоит конкретная техническая философия — MACH-архитектура. Это аббревиатура из четырёх принципов, которые определяют, как строится система.

Microservices — каждая функция магазина реализована как отдельный сервис. Каталог отдельно, корзина отдельно, оплата отдельно. Если упадёт сервис рекомендаций — магазин продолжит работать, просто без блока «С этим товаром покупают».

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

Cloud-native — инфраструктура живёт в облаке и масштабируется автоматически. Чёрная пятница — серверы подстраиваются под нагрузку. Тихий вторник — ресурсы освобождаются, расходы снижаются.

Headless — фронтенд отделён от бэкенда. Дизайнер и фронтенд-разработчик создают интерфейс на любой технологии — Next.js, Nuxt, Astro — и подключают данные через API. Можно иметь несколько фронтендов: сайт, мобильное приложение, голосовой интерфейс для Алисы — и все используют одни и те же API.

Как это выглядит на практике

Позвольте показать конкретный пример, чтобы стало понятнее. Допустим, мы строим интернет-магазин электроники с каталогом в 30 тысяч позиций.

Каталог товаров и контент ведутся в headless CMS — Strapi или Directus, если нужен self-hosted вариант на российских серверах. Менеджеры работают с удобной админкой, а данные отдаются через API.

Для поиска и фильтрации подключается специализированный поисковый движок — Meilisearch или OpenSearch. Пользователь вводит «наушники с шумоподавлением до 15000» и получает релевантные результаты за миллисекунды. Встроенный поиск монолитной CMS на таком объёме данных работал бы в разы медленнее.

Платежи идут через ЮKassa или CloudPayments — напрямую через их API. Корзина и чекаут — кастомный микросервис, написанный под конкретную бизнес-логику: промокоды, бонусные баллы, корпоративные скидки.

Доставка — интеграция с API СДЭК, Boxberry, Почты России. Пользователь видит стоимость и сроки для всех доступных способов. Менять логистического партнёра можно без переделки всего магазина.

Фронтенд — Next.js с серверным рендерингом для SEO. Страницы генерируются быстро, Core Web Vitals в зелёной зоне, Яндекс индексирует контент без проблем.

Каждый из этих компонентов заменяем независимо от остальных. Решили перейти с Meilisearch на ElasticSearch? Переписываете один модуль, остальное не трогаете.

Реальные преимущества, которые я вижу в проектах

Первое — скорость разработки фич после начального этапа. Да, начальная настройка composable-стека сложнее и дольше, чем установка Битрикса. Но когда архитектура выстроена, новые функции добавляются быстрее. Нужна подписочная модель? Подключаете сервис рекуррентных платежей, не влезая в код каталога. Нужна персонализация? Добавляете ML-сервис рекомендаций, не трогая корзину.

Второе — производительность под нагрузкой. Каждый сервис масштабируется отдельно. В момент распродажи нагрузка на каталог и корзину вырастает в десять раз, а на раздел «О компании» — нет. Composable позволяет направить ресурсы именно туда, где они нужны.

Третье — отсутствие vendor lock-in. Вы не привязаны к одному поставщику. Если завтра Strapi перестанет вас устраивать — переходите на Payload CMS, меняя только один слой. С монолитной CMS миграция — это проект на полгода.

Четвёртое — устойчивость. Если падает сервис рекомендаций, магазин продолжает работать. В монолите ошибка в одном модуле может положить весь сайт.

Когда composable commerce оправдан

Этот подход имеет смысл при совпадении нескольких условий.

Каталог больше десяти — пятнадцати тысяч SKU. При таком объёме монолитные CMS начинают тормозить — фильтры работают медленно, генерация страниц занимает секунды, полнотекстовый поиск даёт нерелевантные результаты.

Высокая нагрузка — сотни и тысячи заказов в день. Если система не справляется с пиками, вы теряете деньги. Composable масштабируется гранулярно, а не целиком.

Сложная бизнес-логика. Разные цены для B2B и B2C-клиентов, многоуровневые скидки, партнёрские программы, мультисклад, мультивалютность — всё это проще реализовать в виде отдельных сервисов, чем пытаться впихнуть в монолитную CMS через плагины.

Команда разработки. Composable требует разработчиков, которые понимают API, микросервисную архитектуру, DevOps-практики. Без команды с релевантным опытом проект превратится в долгострой.

Когда composable НЕ нужен

Скажу честно: для 80 процентов интернет-магазинов в России composable commerce — избыточен. И это нормально.

Если у вас до пяти тысяч товаров и до ста заказов в день — InSales, 1С-Битрикс или WooCommerce закроют все потребности. Они дешевле, быстрее в запуске, проще в обслуживании. Нанять разработчика на Битриксе проще, чем найти архитектора микросервисов.

Если нет штатной команды разработки — composable превращается в головную боль. Кто будет мониторить десять сервисов вместо одного? Кто будет обновлять зависимости? Кто починит интеграцию, когда API-партнёр изменит формат ответа?

Если бюджет ограничен — composable стоит дорого на старте. Архитектура, DevOps, интеграции, тестирование — всё это требует инвестиций. Для стартапа с MVP лучше начать с монолита и мигрировать позже, когда появится product-market fit и стабильная выручка.

Типичные ошибки при переходе на composable

Из моей практики — три самых распространённых промаха.

Первая ошибка — начинать с composable сразу. Классика: стартап без единого клиента закладывает микросервисную архитектуру на старте. Через полгода разработки продукт ещё не запущен, бюджет потрачен, а бизнес-модель так и не проверена. Начинайте с монолита, масштабируйте по мере роста.

Вторая ошибка — делать слишком много микросервисов. Каждый сервис — это отдельная инфраструктура, мониторинг, деплой. Если у вас 40 микросервисов при команде из пяти человек — вы будете тратить всё время на поддержку, а не на развитие. Лучше пять крупных сервисов, чем сорок мелких.

Третья ошибка — недооценивать DevOps. Composable без нормального CI/CD, мониторинга, логирования и алертинга — это бомба замедленного действия. Когда у вас десять сервисов и ни один не покрыт мониторингом, вы узнаете о проблеме от клиента, а не из алерта.

Сколько стоит переход

Грубая оценка для среднего интернет-магазина: переход с монолитной CMS на composable-архитектуру — от двух до шести месяцев работы команды из трёх — пяти разработчиков. Это существенные инвестиции, и они должны быть обоснованы конкретными бизнес-задачами, которые монолит не решает.

Оптимальный путь — поэтапная миграция. Сначала выносите самую проблемную часть — например, поиск. Подключаете Meilisearch через API, остальное пока на старой CMS. Потом выносите каталог. Потом корзину. Каждый этап приносит измеримый результат и не блокирует работу магазина.

Итог

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

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

Если вам нужна оценка, готов ли ваш проект к composable-архитектуре — пишите, разберём вашу ситуацию.